Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Bei Neuanlage eines DS prüfen, ob Index schon vorhanden

Begonnen von WEdith, Februar 21, 2011, 15:10:22

⏪ vorheriges - nächstes ⏩

WEdith

Hallo an Alle!

Vielleicht hat jemand von Euch eine Lösung für mein kleines Problem (Access 2007):
Ich habe eine Auftragsdatenbank angelegt, unter anderem mit den Tabellen Auftrag und Rechnungdetail.  Diese sind mit einer 1:n Beziehung über das Feld Auftragnummer verbunden.
Die Auftragnummer hat einen Index (ohne Duplikate).

Das Problem tritt dann auf, wenn ein neuer Auftrag im Formular angelegt wird, die Auftragnummer aber bereits vorhanden ist. Das kommt vor, da mehrere Personen mit der DB arbeiten und einige Arbeitsschritte von dem Beschaffungsantrag bis zur endgültigen Verbuchung der Rechnungen abzuarbeiten sind.

Als Lösung stelle ich mir vor, dass bei einer Neuanlage, beim Verlassen des Feldes Auftragnummer der Wert überprüft wird und bei Eindeutigkeit tatsächlich ein neuer Datensatz angelegt wird. Sollte der Auftrag schon vorhanden sein, soll auswahlweise der vorhandene Datensatz aufgerufen werden können, oder nochmal ein neuer Datensatz eingegeben werden können.

Bisher habe ich eine Ereignissprozedur beim Verlassen des Feldes Auftragnummer hinterlegt (DoCmd.RunCommand acCmdSaveRecord). Zumindest muss man jetzt nicht erst alle Daten eingetippt haben, um zu erfahren, dass der Auftrag schon angelegt ist...

Was natürlich ganz toll wäre: Ein Eingabefeld für die Auftragsnummer im Formular: Falls die Nummer neu ist wird ein neuer Datensatz angelegt, falls sie schon vorhanden ist, wird der vorhandene Datensatz aufgerufen.

Es wäre prima, wenn mir jemand einen Stoss in die richtige Richtung geben könnte.   LG Edith

DF6GL

Hallo,


ich würde in einem solchen Fall anders vorgehen:

In ein ungebundenes Textfeld gibst Du eine Auftragsnummer ein. Mittels Ereignis "Nach Aktualisierung" des Textfeldes prüfst Du auf Vorhandensein der Auftragenummer (Dlookup, bzw. DCount).

Gibt es sie, dann filterst Du das Form und zeigst den Auftrag an. Gibt es sie nicht, positionierst Du auf einen neuen DS und schreibst die Auftragsnummer aus dem Textfeld in das gebundene Textfeld "Auftragsnummer")


Anstelle des ung. Textfelder kannst Du auch ein Suchkombi benutzen, dessen Eigenschaft  "Nur Listeneinträge" auf JA steht. Im Kombi-Ereignis ""Bei nicht in Liste" positionierst Du wie oben gesagt auf einen neuen DS und schreibst den im Kombi eingegebenen Wert (Argument "Newdata" in der Ereignisprozedur)   in das Feld "Auftragsnummer"


WEdith

Hörst sich gut an! Dazu hätte ich aber noch zwei Fragen:

1. Funktioniert das Filtern der Form auch, wenn ich eine geteilte Form habe? (Oben der aktuelle DS, unten in Tabellenform alle angelegten)

2. Könnte man das ungebundene Feld so platzieren, dass dem Benutzer nur ein Feld vorgegaukelt wird?

lg Edith

DF6GL

Hallo,



1) warum nicht,  die "Erscheinungsform" des Formulares hat nicht allzuviel zu tun  mit der Filterung.


2) warum?  Ich denke, der User wird dadurch eh nur verwirrt, weil er nicht weiß, was er gerade vor sich hat, das Suchfeld oder das "richtige" Anzeigefeld. Außerdem gäbe es Datenchaos, wenn man fälschlicherweise den "Suchwert" in das Anzeigefeld schreibt. Klar könnte das abgestellt werden, wenn das Anzeigefeld gesperrt wird, aber das schränkt halt nun weitere Pflege-Möglichkeiten am Auftrag ein.  Im Grunde kannst aber nur Du das beantworten, inwieweit Userzwänge sich produktiv/effizient auswirken.