Plötzlich auftretender LZF 2455

[laola]

Hallo zusammen,

ich habe eine Datenbank seit über einem Jahr am Laufen. Seit ein paar Tagen tritt in einer nicht geänderten Funktion ein Laufzeitfehler auf. Wir nutzen Access 2007.

Die Funktion ist im Groben, aus einem zentralen Startformular ein anderes Formular zu öffnen und in diesem Unterformulare dynamisch die Datenquelle zuzuweisen.
Der Fehler tritt auf in dem Moment, in dem die Recordsource gesetzt werden soll.

Im Folgenden Auszüge des Codes:

Code [Auswählen] Erweitern


'Öffnen der Formulare und Anpassen der Datenherkunft
DoCmd.OpenForm "F_ReKo", acNormal, , , , acHidden
With Forms("F_Reko")
    !Registersatz.Pages("ReKo_1").Caption = Bezeichnung     'Titel 1. Reiter anpassen
    !Registersatz.Pages("ReKo_2").Visible = ReKo_2          '2. Reiter ein-/ausblenden
    !Registersatz.Pages("ReKo_3").Visible = ReKo_3          '3. Reiter ein-/ausblenden
    !Registersatz.Pages("ReKo_4").Visible = ReKo_4          '4. Reiter ein-/ausblenden
    !Registersatz.Pages("ReKo_5").Visible = ReKo_5          '5. Reiter ein-/ausblenden
    .RecordSource = strSQL_F_ReKo                           'Datenherkunft Hauptformular anpassen
>>> Hier bleibt der Code mit Fehler 2455 stehen:
    !UFo_NP_ABG.Form.RecordSource = "A_NP_UserDaten_Kpl"    'Datenherkunft Häkchenfeld anpassen
    !UFo_NP_ABG!ReKo_Abg.ControlSource = ctl_UF_NP_Abg      'Datenherkunft Häkchenfeld anpassen
    !UF_ReKo_1.Form.RecordSource = strSQL_UF_ReKo_1         'Datenherkunft 1. Detailformular anpassen
    !UF_ReKo_2.Form.RecordSource = strSQL_UF_ReKo_2         'Datenherkunft 2. Detailformular anpassen
    !UF_ReKo_3.Form.RecordSource = strSQL_UF_ReKo_3         'Datenherkunft 3. Detailformular anpassen
    !UF_ReKo_4.Form.RecordSource = strSQL_UF_ReKo_4         'Datenherkunft 4. Detailformular anpassen
    !UF_ReKo_5.Form.RecordSource = strSQL_UF_ReKo_5         'Datenherkunft 5. Detailformular anpassen
End With
DoCmd.Maximize
Forms("F_Reko").Visible = True


Nach langem Suchen im Internet bin ich leider immer noch keinen Schritt weiter. Was mich aber wirklich wundert, ist dass wir diese Funktion seit über einem Jahr ohne Probleme so genutzt hatten und der Fehler erst sein wenigen Tagen (ca. <8 Tage) auftritt.

Falls irgendjemand eine Idee hat, was ich versuchen könnte wäre ich sehr dankbar.

Viele Grüße
Simon

[DF6GL]

Hallo,

ist "UFo_NP_ABG"  der Name des UFO-Steuerelementes im Form "F_Reko" ?

[laola]

Ja, "UFo_NP_ABG" ist der Name des UFO-Steuerelementes im Form "F_Reko", das Unterformular selbst heißt "UF_NP_ABG".

[DF6GL]

Hi,

wenn möglich , lad mal den relevanten Teil der DB hier hoch (komprimiert/repariert und gezippt), damit das nach zu vollziehen ist.

[laola]

Hallo,

ich habe die Fehlerursache gefunden. Es lag tatsächlich daran, dass in der Zeile, vor der der Code stoppte, die Datenherkunft des Hauptformulars geändert wird. Und hier hatte sich eine ungültig SQL-Syntax generiert. Leider bin ich erst jetzt auf die Idee gekommen, dies zu prüfen. Nach deren Korrektur läuft das Programm nun sauber durch.

Hat jemand eine Idee, wie ich einen solchen Fehler abfangen könnte? Die Datenherkunft des Hauptformulars zu verifizieren?

Danke für die bisherigen Bemühungen.

Viele Grüße,
Simon

[ebs17]

Hat jemand eine Idee, wie ich einen solchen Fehler abfangen könnte?

In der Prozedur fallen bei Dir Variablen und deren Inhalte "vom Himmel", sprich da werden Variablen ohne nähere Information verwendet, und diese holen sich irgend woher Inhalte.
Übersichtlicher wird es, wenn Du eine Prozedur mit Eingangsargumenten verwendest, der dann bei Aufruf die Inhalte für diese Argumente übergeben werden. An dieser Schnittstelle kann man recht gut verifizieren.

Und hier hatte sich eine ungültig SQL-Syntax generiert.

Von alleine?
Syntaxanforderungen von SQL an sich sind nicht dynamisch. Daher würde man hier dem Entwickler etwas mehr Sorgfalt empfehlen.

[laola]

Hallo Eberhard,

grundsätzlich und generell bin ich der gleichen Meinung.

Allerdings wird in meinem Code tatsächlich aufgrund von Daten und abhängig vom anwendenden Benutzer dynamisch eine SQL-Syntax erzeugt. z.B. wird der Feldname, der als Filter verwendet wird oder aus dem die Daten verwendet werden, dynamisch erzeugt.
Im aktuellen Fall ist hierbei eine Kombination aufgetreten, die
a) so nicht vorgedacht war
und b) so auch nicht geplant war.

Diese Werte und Ergebnisse alle einzeln zu prüfen wäre recht umfangreich. Daher kam mir die Frage bzgl. der Möglichkeit, die Funktion des Formulars nach dem Zuweisen der Datenherkunft zu verifizieren.

Viele Grüße
Simon

[MaggieMay]

Hi,

um es noch einmal unmissverständlich zum Ausdruck zu bringen:

Und hier hatte sich eine ungültig SQL-Syntax generiert.

Da musst du wohl an der Stelle ansetzen, wo der SQL-Code generiert wird - wo sonst?

Zeig doch bitte mal den VBA-Code dazu und auch ein Beispiel für einen fehlerhaften SQL-Code.

[ebs17]

Noch mal: Du kannst keine SQL-Syntax erzeugen, sondern nur eine SQL-Anweisung, die der notwendigen Syntax entspricht - oder eben nicht.

Kombination aufgetreten, die
a) so nicht vorgedacht war
und b) so auch nicht geplant war

... also Handeln eilt dem Denken voraus. Hier ist der Entwickler gefordert, was sonst.

z.B. wird der Feldname, der als Filter verwendet wird oder aus dem die Daten verwendet werden, dynamisch erzeugt

Nach einem Feld, dass es bis dahin gar nicht gibt, wird gefiltert? Du siehst, eine solche "Erklärung" schafft keine Klarheit.