Office: (Office 2003) Textfeld Datensatz x von y

Unterscheidet NotInList Groß-/Kleinschreibung?

ok, ich versuch mal, diese Private Sub zu erstellen *für dlookup-Funktion gleich mal in die Hilfe schau*

... wie meinst du das bzw wo siehe oben?

LG ANja

 

... also ich bin mir noch nicht ganz klar darüber, ob ich nun VB toll finde oder nicht *wink.gif* ...

Das liegt aber nicht an dir, Maike - DU bist ne tolle Lehrerin *Smilie ... Denn Dein Hinweis

ist mir schon ein guter Wegweiser. Zumindest hab ich ne Vorstellung, was ich da umsetzten sollte:

Also ich soll im BeforeUpdate-Ereignis eine Prozedur erstellen, die das Feld Zname in der Tabelle T2_Zutaten mit dem Eintrag des Textfeldes Zname (das Textfeld befindet sich im UFO "F2_UF1_Zutatenliste", dies ist im Hauptformular "F2_neue Zutaten" eingebunden im Steuerelement "Zutatenliste" dieses Hauptformulares) abgleicht und bei Übereinstimmung eine Fehlermeldung bringt. Das Speichern (durch Klick des ok-Button im Hauptformulares) wird dadurch abgebrochen. Ist das so richtig? *biggrinlove

OK, nun mein erster Versuch eines selbst geschriebenen VBA-Objektes. Private Subs sind doch Objekte oder Klassenobjekte oder sowas? Wie auch immer, das ist jedenfalls schon anspruchsvoller, als die "Assis"-Codes nur simpel "anzupassen" (sprich die Namen abändern und ggf mehrere cmd- oder andere Befehle nach Wunsch aneinanderzureihen).

Das, was ich da erstellt habe, funktioniert aber auch nach 4 Stunden immer noch nicht *knurr* - nun ja, vielleicht ist es ja doch ziemlicher "Unsinn" und mein Editor lacht sich derweil scheckig *wink.gif* ... Oder vielleicht war dein Hinweis "wenn ja, den zweiten verhindern - Einschränkung siehe oben" doch elementar wichtig dabei und ich hätte lieber erstmal deine Antwort auf #61 abwarten sollen, bevor ich loslege?

Anbei MEIN Code (eingebettet im UFO; als Ereignis vor Aktualisierung des Textfeldes Zname) ... ich hoffe, es sieht wenigstens so aus, als sei es ein VBA-Code:

Code:

... anbei auch nochmal die Privat Sub des OK-Button vom Hauptformular (die funzt ja so wie es soll):
Code:

naja, nu geh ich halt ohne dieses Erfolgserlebnis ins Bett *rolleyes.gif* . ...

P.S. Ich hab inzwischen auch alles für die SuFu fertig (das Formular und die Abfragen (SQL)) ... Nur den Ergebnisbericht (für die Suchergebnisse) muss ich noch erstellen *Smilie ... Aber dass dann alles mittels VBA zu implementieren und zu verbinden ... *entsetzt *zitter*...

Gute Nacht

LG ANja

 

Moin Anja,
der Code ist prima. Ich vermute, er ist nur an der falschen Stelle ...
Kriegst du eine Fehlermeldung? Dann bitte immer mit posten.
Lad deine DB doch noch mal hoch in der jetzigen Version.
Und wegen SQL und VBA brauchst du dir keine Sorgen zu machen, das kriegst du hin.
maike

 

echt? der Code ist prima? *winner

nein, es kommt keine Fehlermeldung. Es passiert augenscheinlich .... n i c h t s.
Es ist so, als wäre die Prozedur gar nicht da.

Deshalb habe ich schon spekuliert, ob nicht die Buttonprozedur und mein Code irgendwie "gegeneinander" oder "aneinander vorbei" arbeiten ...

Meine Überlegung: Die button-Prozedur aktualisiert ja u.a. das UFO. Möglichweise greift des halb meine beforeUpdate-Prozedur für dieses Textfeld des UFO nicht?

EDIT: OK, anbei noch die aktuelle Version der DB ....

LG Anja

 

Sodele. meine Vermutung war richtig, falsche Stelle. Und ein paar kleine Schönheitsfehler - bei uns beiden *biggrin.gif* .
Beim Dlookup fehlte noch der Vergleich >"" (Wenn dlookup-Ergebnis größer als nix).
Und die Prüfung muss beim Speichern-Button eingebaut werden, sonst spuckt sich das tatsächlich in die Suppe. Geprüft werden muss das Feld im Hauptformular - Klein-/Großschreibung interessiert dabei übrigens nicht, apfel wird netterweise genauso angemeckert wie Apfel.
Hier ist der Code, den musst du noch für den Close-Button anpassen, damit die Prüfung auch stattfindet, wenn jemand direkt auf den klickt. Und aus dem Ufo beim BeforeUpdate alles wieder raus.
Code:

maike

 

ah *Smilie ...

... habe noch DoCmd.GoToRecord , , acNewRec eingefügt, weil das Feld geleert werden soll *Smilie (bei beiden ButtZUTATSPEICHERN_Click() und ButClose_Click()

Aber probier das mal aus bei beiden und schau hinterher in die Zutatentabelle *upps
liegt es an meinem DoCmd acNewRec??

ButClose_Click()
vorher:
Code:

nachher:
Code:

ButtZUTATSPEICHERN_Click()
vorher:
Code:

nachher:
Code:

anbei auch die neue DB-Version mit den Änderungen

es grüßt herzlich Anja

 

Das wieder raus, weil du doch den Datensatz im If-Fall nicht speicherst - er ist dann immer noch der neue. Das Feld wird mit Me!Zname.Undo leer gemacht. Und wenn du zu einem neuen Datensatz gehst, wird der leere womöglich gespeichert.
maike

 

ok, hab es entfernt ... aber da ist trotzdem was seltsam. Es steht hinterher eine neue ZID ohne Zname in der Tabelle ... habe aber nicht genauer getestet, durch welche Prozedur der Eintrag entsteht ...

UND das Feld wird nicht geleert, es bleibt der falsche Eingabewert drin stehen

anbei die neuste Version mit den Änderungen, ohne die 2 Befehle DoCmd.GoToRecord , , acNewRec

LGAnja

 

Jup. Da haben wir jetzt ein kleines logistisches Problem. Das Eingabefeld ist an die Tabelle gebunden, dadurch entsteht ein neuer Datensatz, sobald da etwas reingetippt wird oder wurde. Ich stelle das Formular mal um (das braucht kein Ufo, sach ich doch schon seit mindestens 10 Posts *wink.gif* ) und baue eine erste VBA/SQL Prozedur rein - da hat das dann gleich auch sein Gutes *biggrin.gif*
maike

 

Anbei die Datenbank. Den Button Close überlasse ich wieder dir *wink.gif* .
maike

 

oh danke .... rein datentechnisch muss da wirklich kein UFO rein, weil nur eine Tabelle zugrunde liegt (du meinst doch F2?) ... ich wußte halt nicht, wie ich es anders machen soll, dass man ein schönes Eingabefeld mit Knöpfsche hat und andererseits auch gleich die komplette Zutatenliste nachsehen kann ...


oho *biggrinlove dann überflieg doch auch mal kurz den "VB-Code" fürs F3 ..... das sind so meine "VB-Gedanken" ... *wink.gif* *gespanntbin*

... ich mach jetzt mal den Bericht für die Suchergebnisse (ich hoffe, dass einer reicht und ich nicht mehrere brauche ...)

EDIT .... das hatte sich wohl überschnitten mit dem vorherigen Post. ... also dann mach ich den CloseButton und den Bericht für die Suchergebnisse

DANKE für das schnelle Ergebnis ich schaus mir gleich mal an *Smilie

LG ANja

 

.... mmh da ist noch was nicht ganz io ....

soll ich jetzt mal diesen Tread 'Datensatz x von y' schließen und einen neuen mit dem aktuellen Thema öffnen?


edit ... ist vielleicht nicht mehr nötig: Habe die Ursache gefunden (die ich auch selbst verursacht habe *redface )

also folgendes:
1)
nach erfolgreicher Eingabe (OK Button) leert sich das Eingabefeld nicht und der Focus rutscht auf 1. DS im Detailbereich (wenn dann Click auf XButton oder noch mal auf OKButton, wird die doppelte Zutat angemeckert):
Feld soll sich nach Eingabe leeren und den Focus anschließend neu erhalten

2)
wenn doppelte Zutat eingegeben wurde (Click OK oder Click X), wird in Tabelle Zutaten eine neue ID ohne Zname gespeichert

3)
eine eine neue ID ohne Zname wird auch dann in der Tabelle gespeichert, wenn zunächst zwei neue Zutaten ordnungsgemäß gespeichert werden, dann das Eingabefeld geleert wird und anschließen der XButto geclickt wird --->

oh *eek.gif* daraus folgt also:

Der Grund für 2+3 liegt in der Prozedur für den xButton *grinangel ok, also da hab ich was verbockt und dann habe ich darüber nachgedacht und hatte dann auch den Einfall, dass es keinen Sinn macht, beim schließen Einträge zu speichern - gespeichert wird mit OK - Punkt.
Nicht mal ein DAU käme auf die glorreiche Idee, neue Einträge durch X speichern zu wollen *laugh SCNR SCNR ... Sollten wir nicht lieber davon ausgehen, dass er das schon voher mit OK tut und erst danach X anklicken wird??

... Überlegungenzu Lösungsmöglichkeiten hatte ich: habe die dezeitige (noch fehlerbehaftete) DB-Version beigefügt, und ich habe Anmerkungen in den aktuellen (flaschen) Code gemacht. Ich glaube, das ist gar nicht so schlecht, was ich mir da so zusammengereimt habe.

hab hier noch ne kleine Bitte:
Code:

Grüßle Anja

 

Das ist so das Leben, an irgendwas denkt man immer nicht *biggrin.gif*

Am besten setzt du
Code:

im Code ganz nach unten (vor das Exit), das Feld soll ja sowohl bei Doppelung wie auch bei Speichern wieder geleert werden und den Fokus bekommen.

Wer ist "er" *watch ? Nee, davon sollten wir nicht ausgehen - "er" ist mit Sicherheit Murphy.
Den Code beim X-Button guck ich mir morgen irgendwann nochmal an.

mit Debug.Print kannst du dir den fertigen SQL-String im Direktfenster ausgeben lassen, da sieht man dann oft, wo noch etwas hakt. Das Direktfenster kannst du dir über das Menü (Ansicht oder Fenster oder so ..., habs grad nicht im Kopf, es gibt auch irgendeine Tastenkombi, die mir ebenfalls entfallen ist *eek.gif* ) irgendwo einblenden, falls es bei dir nicht sichtbar sein sollte.

CurrentDb ist die aktuelle Datenbank, Execute heißt ausführen und dbFailOnError als Option bewirkt, dass dir wie bei Abfragen Fehler in der SQL-Syntax angezeigt werden.

Me ist das aktuelle Formular. Nach dem Requery springt es auf den ersten Datensatz zurück. Lässt sich aber ändern, wenn du lieber den neu eingegebenen Eintrag oben haben möchtest.
Morgen *tongue.gif*
maike

 

Hallo,

die Tastenkombination, die Du sucht, ist STRG + G.

Diese Tastenkombination funktioniert nicht nur im VBA-Editor sondern auch in Access.

CU

 

Wie meinst Du das? Per SendKeys() mitten im Programm??