Office: (Office 2010) rs.eof wird nicht erreicht.

Moin zusammen,

ich steh beim Durchlauf einer Schleife grad vor dem für mich nicht nachvollziehbaren Phänomen, dass .EOF "nicht erreicht" wird.

Ich baue hiermit ...

Code:

eine Art Packschein als Textstring zusammen. Der wird auch korrekt erzeugt: Das RecordSet liefert die richtigen Daten; die Schleife erzeugt laut rot markiertem "debug.print" inhaltlich den richtigen String.

Problem: rs.eof springt nicht auf TRUE, wenn die Schleife laut Daten abgearbeitet sein sollte, sondern beginnt von vorne. String leer, und wird neu zusammengesetzt. Endlos.

Problem Level 2: Passiert nicht immer. Aber inzwischen oft genug, dass ich es abstellen möchte. Ich erkenne aber ums Verr...en nicht, warum rs.eof nicht erkannt / ausgelöst wird, wenn es denn passiert.

Klingt wirr, isses auch. ;-)

Jemand eine entwirrende Idee?

Danke!
Andre.

:)

 

Was macht Debug.Print rs.EOF, wenn Du es NACH dem MoveNext setzt?

 

Code:

So lautet Deine Abbruchbedingung. Sie kann nur bei leerem Recordset oder nach einem MoveNext erreicht werden.

Für einen Fortgeschrittenen wie Dich ist das ein chaotischer Code. Neu und ordentlich schreiben.

Code:

Alles unnötig. Beim Neuöffnen eines Recordsets steht der Datenzeiger auf dem ersten Datensatz oder auf EOF (wenn rs leer).
DLookup in Schleife ist schlimm. Verwende eine richtige SQL-Anweisung als Datenbasis für das Recordset.
Inhalt HAVING sollte WHERE sein.
Recordset schließen nicht vergessen.

 

Ja, die Position von "debug.print" war tatsächlich blöd gesetzt. Dann wird an der erwarteten Stelle ein WAHR draus ... die Schleife beginnt aber dennoch von neuem.

So lautet Deine Abbruchbedingung. Sie kann nur bei leerem Recordset oder nach einem MoveNext erreicht werden.

Das ist ja genau mein Problem: Ich erreiche nach Anzahl X von MoveNext meinen .EOF, die Schleife beendet aber nicht.
Oder verstehe ich den Hinweis nicht/falsch?

Alles unnötig. Beim Neuöffnen eines Recordsets steht der Datenzeiger auf dem ersten Datensatz oder auf EOF (wenn rs leer).
DLookup in Schleife ist schlimm. Verwende eine richtige SQL-Anweisung als Datenbasis für das Recordset.
Inhalt HAVING sollte WHERE sein.
Recordset schließen nicht vergessen.

Da ist einiges an "Debug-Resten" drin, und das ist mir bewusst. Und für Ablaufoptimierungen hab ich immer ein offenes Ohr. Ich würde das Putzen und Rundschleifen aber aufschieben wollen, bis der eigentliche Fehler gefunden ist, der den (meinetwegen suboptimalen) Ablauf gerade mehr behindert, als die genannten Suboptimalitäten. Einverstanden? ;-)

 

Also, überarbeitet ....

Code:

Mehr Hintergrund: Die Routine erzeugt pro Lieferschein einen Textstring aus allen Prüfmitteln, die Stand aktueller Lieferschein noch nicht bearbeitet wurden.

Mich verwirrt dabei: Ab und zu hab ich einen Lieferschein (aktuell einen aus 14 des gleichen Auftrags), wo der identische Ablauf in eine Endlosschleife geht. Bei den 13 anderen Lieferscheinen läufts. Aus 100 Aufträgen hab ich 2, wo das Problem überhaupt auftritt.

Ich erkenne den Grund nicht.

 

Du kommst nie nach dem Loop an? Das kann eigentlich nur sein, wenn in der Schleife das MoveNext fehlt (Endlosschleife).

Eventuell könnte es sein, dass der Code durch die DLookups (Externe Abfrage) irgendwohin stiften geht. Daher würde ich wie gesagt die zu ermittelnden Werte gleich in die SQL-Anweisung bringen, mit der das Recordset erzeugt wird, dann braucht man nur eine kommagetrennte liste (SQLListe) erzeugen.

 

Nicht "nie". Aber ab und an. Ich kanns leider nicht besser erklären.

Der erzeugte SQL-String ist in korrekt, und an der jetzt richtigen Stelle wirft "Debug.Print rs.EOF" ein "Wahr" aus, wo es zu erwarten wäre.

Aber die Schleife beginnt trotzdem von vorn, ich sehe per "Debug.Print strPMListeNochOffen", dass die Liste neu zusammengesetzt wird. Von vorne, wieder komplett, und wieder von vorne.

 

Das klang sexy ...

Code:

... Ergebnis ist unverändert: Schleife baut den String auf, geht an .EOF=Wahr vorbei und in die nächste Runde, usw.

 

Code:

Verwende testhalber statt des DLookups den Recordsetwert selber, bzw. irgendeine Konstante.

Ich kann mir nicht wirklich vorstellen, wie die Schleife ohne zusätzliche Maßnahme von vorne beginnen sollte.
Aber, schon aus Prinzip und hier vielleicht extra hilfreich:
Code:

Als Standard wird Dynaset verwendet. Recordset muss neben Lese- uauch Schreibvorgänge verwalten, ist damit das aufwändigste und langsamste.
Code:

Code:

Diese Prüfung ist etwas sinnfrei, weil Du der Variablen in jedem Fall einen Inhalt zuweist, es sei denn das Recordset ist leer.
Hier kann das Recordset nur einmal von vorne vorwärts durchlaufen werden. Das wäre schon wegen der Nutzung des Recordsets die logische und schlanke Variante. Optimierung trifft Funktionalität, und zwar gleich und nicht irgendwann später.

 

Das ist genau hier reproduzierbar?
=> Demo-DB

 

Ich glaube, wir bewegen uns drauf zu:

Wenn ich auf die "Auflösung" der PM-ID in die PM-Nummer ganz verzichte, egal ob in der SQL des Recordsets, oder in der Zusammensetzung des Strings, funktioniert die Schleife scheinbar.

Ich hab gerade mal den Dlookup in den SQL-String des Recordsets verlegt: Problem wieder da.
Auflösung, ebenfalls im SQL-String des Recordsets, aber per Join auf die entsprechende Tabelle: Problem auch wieder da.

Teste das noch weiter.

 

Und jetzt steige ich mit meinem begrenzten Sachverstand endgültig aus:
Ich hab jetzt das Reordset auf 3 unterschiedliche Arten zusammengebaut:

Code:

... alle 3 Varianten funktionieren, bis ich beim Auswerten des Recordsets hier ...
Code:

... etwas anders ausgeben will als "[APM_PruefmittelID]": Endlos-Schleife.
Mit Ausgabe "[APM_PruefmittelID]": Sauberes Schleifen-Ende.

Nach wie vor in 1 von 14 Belegen eines Auftrags.

 

=> #10

Das Feld sollte aber schon in der SQL-Anweisung vorkommen.

 

Schon klar. Hab es auch nur eingetragen, wenn vorhanden. Andernfalls ensteht auch keine Endlos-Schleife, sondern eine deutliche Abbruch-Meldung.

 

Man kann ja nur beurteilen, was Du vorlegst.

In der dritten und verwendeten SQL-Anweisung fehlen trennende Leerzeichen.
Wenn beim Testen wechselnd zusätzliche Fehler eingebaut werden, wird es nicht einfacher und übersichtlicher.