Februar 27, 2021, 16:50:09

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Beziehungen zwischen 3 Tabellen verursachen Fehler beim Requery

Begonnen von yme24, Januar 21, 2021, 07:57:36

⏪ vorheriges - nächstes ⏩

DF6GL

Hallo,


Db anbei..


Zitatpasst die Eingabereihenfolge nicht und ich kann so auch nicht die korrekten (der jeweiligen Firma zugeordneten) Ansprechpartner filtern

Was heißt Eingabereihenfolge?

Filtern siehe DB

yme24

Hallo Franz,

Danke für deine Hilfe.

Zitat von: DF6GL am Januar 25, 2021, 15:52:13Was heißt Eingabereihenfolge?

Mein Eingangspost:

Die Postbearbeitung soll folgende Reihenfolge bei der Eingabe haben:

Postrichtung, Art, Kategorie, Kontakt (sprich Firma), Ansprechpartner (alles Kombifelder bis hierhin) und anschließend alle Postdaten (Eingangsdatum, etc.) in Textfeldern.



In der Form, die du dankbarer Weise erstellt hast, steht der Ansprechpartner als "führende" Eingabe.

Eine eventuell mögliche Reihenfolge wäre auch Firma, Ansprechpartner, Postrichtung, Art, Kategorie, ...
Das muss ich aber erstmal prüfen - besser wäre es so wie eingangs geschrieben.

So wie ich das sehe, kann man das nicht ohne weiteres abändern, oder?


Gruß,
Martin


DF6GL

Hallo,

das kann im Formularentwurf/Eigenschaften  bei "Reihenfolgeposition" und "in Reihenfolge" unter Reiter "AllE" eingestellt werden.

yme24

Hallo Franz,

ich habe es heute nicht eher geschafft, hier rein zu schauen.

Ich glaube, ich habe mich missverständlich ausgedrückt - bitte entschuldige.

Es geht mir nicht um die Aktivierungsreihenfolge der Felder, sondern um die Reihenfolge in der sie zu befüllen sind.

Inzwischen habe ich mit den Kollegen gesprochen.
Die Reihenfolge: Richtung, Art, Kategorie, Kunde, Ansprechpartner ist nach wie vor favorisiert, weil bisher auch so verfahren wird und diese Rangfolge auch für die Weiterbearbeitung den meisten Sinn ergibt.
Die Reihenfolge Kunde, Ansprechpartner, Richtung, Art, Kategorie erfordert eine Umstellung, geht aber auch.

Die (aktuelle) Reihenfolge deiner Beispiel DB ist Ansprechpartner, Firma, Richtung, Art, Kategorie und unpraktisch, da so der "Filter" über die Firma entfällt und somit immer alle Ansprechpartner im ersten Kombi-Feld erscheinen.

Wenn du dir meine eigene DB (hochgeladen am Montagmorgen) anschaust, siehst du wie die Reihenfolge definiert ist. Die Rowsource im Kombifeld des Ansprechpartners dient als Filter Kunde - Ansprechpartner

Du hast mich aber mit deiner DB auf eine Idee gebracht, die ich mal probieren werde. Ich melde mich ob es geklappt hat. Vielen Dank bis hierhin.

VG,
Martin



yme24

Hallo Franz,

ich habe es auf Basis meiner ursprünglichen Idee hinbekommen. Ich habe für das fragliche Feld ASPID_F eine IsNull Funktion generiert, die verhindert, dass die DB nach dem Requery einen Nullwert vorgesetzt bekommt.
Auf die Idee hast du mich mit der Anordnung der Felder gebracht - vielen Dank dafür.

Jetzt habe ich aber ein Problem an gleicher Stelle, bei dem ich nicht weiterkomme. Ist aber glaube ich ein eher syntaktisches Problem, das bei meiner Testerin aufgetreten ist.

Kurz erklärt:
Ich nutze die Autovervollständigen-Eigenschaft eines Kombifelds für die Auswahl der Ansprechpartner.
Wenn ICH bei der Eingabe der Zeichen feststelle, dass die gesuchte Person noch nicht in der Liste ist, hüpfe ich mit Esc aus dem Feld raus und öffne danach per Knopfdruck ein Formular mit dem ich die Person anlegen kann. -> Das funktioniert Bestens
Meine Testerin nutzt aber nicht die Esc-Taste sondern versucht mit den eingegebenen Zeichen das Formular zu öffnen. Dabei rennt sie in den Fehler, dass "die Zeichen nicht Teil der Liste sind" und kommt nicht weiter. Alternativ hat sie versucht, die Zeichen per Backspace zu löschen und läuft dabei in einen "Sie versuchen eine Null einem Feld zuzuweisen welches kein Variant ist" Fehler.

Ich habe mir gedacht, dass man dem Kombifeld ein Ereignis "beim Verlassen" setze Wert x (also das, was Access macht wenn man Esc drückt) oder so geben kann, ähnlich meiner IsNull Lösung oben. Aber es scheint, als würde Access die Fehlermeldung(en) vorher generieren bzw. die Betätigung des Buttons nicht als Verlassen zu werten.

Mir fällt dazu ehrlich gesagt noch keine Lösung ein, aber vielleicht hast du ja eine Idee?

Vg und schönen Abend,
Martin



DF6GL

Hallo,

Zitat..dass "die Zeichen nicht Teil der Liste sind...

genau dafür gibt es das "Nicht in Liste"- Ereignis, um in dessen Ereignisprozedur z. B. ein Formular zu öffnen, das auf eine Neuen DS gestellt wird und damit gleich der Erfassung einer neuen Person dient.



yme24

Hallo Franz,

hat so geklappt, vielen Dank.

Darf ich dich in diesem Thread noch etwas zum Thema Suchformular fragen?

Ich habe ein Suchformular über Kontakt (sprich Firma) und Ansprechpartner  - jeweils mit Kombifeld - erstellt.
Zuerst dachte ich, es funktioniert, aber dummerweise hatte ich den beiden Kombifeldern ein Steuerelement zugewiesen und damit immer den ersten Datensatz der Tabelle überschrieben.
Wenn ich die beiden Kombifelder aber ohne Steuerelement lasse, weiß ich nicht wie ich mein UFO (mit den Suchergebnissen) an das HFO der Suche verknpüfen soll.

Da muss es doch was "simples" geben, oder?


VG,
Martin



DF6GL

Februar 01, 2021, 11:32:15 #22 Letzte Bearbeitung: Februar 01, 2021, 11:55:44 von DF6GL
Hallo,


Zitathatte ich den beiden Kombifeldern ein Steuerelement zugewiesen

damit meinst Du sicher, dass die Kombifelder an ein Tabellenfeld gebunden sind/waren.


Zitatweiß ich nicht wie ich mein UFO (mit den Suchergebnissen) an das HFO der Suche verknpüfen soll.

Vielleicht beschreibst Du erst mal, wie das Suchformular aufgebaut ist.  Wozu benutzt Du zum Suchen eine HFO/UFO-Konstruktion?


Wenn das HFO ungebunden ist und das UFO Suchergebnisse anzeigen soll, so lass beim HFO die Eigenschaft "Datenherkunft" leer (ungebundenes Form)  und schreibe beim UFO (Endlos-Form) den passenden Tabellennamen in dessen Datenherkunft.


Im HFO werden zwei ungebundene (!) Kombifelder eingebaut mit passender Datensatzherkunft für die Auswahl-Daten (Such-Kriterien) für den Filtervorgang.

Gefiltert (gesucht) wird dann dadurch, indem der Eigenschaft "Filter" des UFOs das aus den Kombifeldern zusammengesetzte Suchkriterium (Where-Condition) zugewiesen wird.

.
.

Sub Kombi1_Afterupdate()
Me!Ufo_Steuerelementname.Form.Filter = "TabID = " & Me!Kombi1
Me!Ufo_Steuerelementname.Form.FilterOn = True
End Sub

yme24

Hallo Franz,

Danke für deine Hilfe. Ich hatte einen Syntax-Fehler in meinem Filter-Code, der mir einfach nicht auffallen wollte. Ich filtere nach der Eingabe im zweiten Kombifeld nun einfach die Datensätze - ohne Schnickschnack.

Na jedenfalls läuft die DB nun (fast) so wie sie soll. Ich habe noch ein Formular, dass ein Requery partout nicht ausführt - das ist aber in meinem Wartungsbereich und fällt im FE nicht auf.

Und, leider halten sich die Anwender(innen) nicht an alle meine Vorgaben (z.B. dass die Hausnummer ein Zahlenfeld ist  ::) ), aber das ist ein Problem, dass man nicht im Forum lösen kann - es sei denn es gibt eine Selbsthilfe hier für leidgeplagte DB-Schreiber  ;D

Nochmals vielen Dank Franz! Bleib gesund!

VG,
Martin

DF6GL

Hallo,


Zitatleider halten sich die Anwender(innen) nicht an alle meine Vorgaben (z.B. dass die Hausnummer ein Zahlenfeld ist  ::) ), aber das ist ein Problem, dass man nicht im Forum lösen kann - es sei denn es gibt eine Selbsthilfe hier für leidgeplagte DB-Schreiber 

Wie ist das denn zu verstehen?

Wenn die Hausnummer den Datentyp "Zahl, Long" hat, dann kann auch nur eine Zahl eingegeben werden.  Kann in einer Hausnummer auch ein Buchstabe vorkommen (z. B. 10a), dann muss das Feld den Datentyp Text aufweisen.  Besser wäre hier allerdings, für den Nummern-Zusatz ein extra Feld mit DatenTyp Text zu spendiern und die eigentliche Nummer bei Datentyp Zahl,Long zu belassen.


Beim Zusatzfeld kann dann eingestellt werden, dass nur bestimmte Buchstaben eingegeben werden können.