Datentypenkonflikt in Kriterienausdruck

[gromax]

Liebe Access-Profis,

ich habe eine DB in zwei Varianten erstellt:
1. Variante
Die DB1 ist in Frontend und Backend aufgeteilt, enthält echte Daten und stellt u.a. den Bericht "rpt_WIEDERVORLAGE" korrekt dar.
2. Variante
Die DB2 ist nicht in Frontend und Backend aufgeteilt, enthält unechte Daten und stellt den Bericht "rpt_WIEDERVORLAGE" nicht dar; die Fehlermeldung lautet "Laufzeitfehler '3464' - Datentypenkonflikt in Kriterienausdruck".

Zum Hintergrund:
Die Berichte werden auf der Grundlage einer Abfrage "qry_Wiedervorlage" erstellt; in dieser Abfrage befindet sich ein berechneter Ausdruck

Code [Auswählen] Erweitern


Schuljahr1: Wenn(DatSeriell(Jahr([BEA_Wiedervorlage]);8;1)<[BEA_Wiedervorlage] Und [BEA_Wiedervorlage]<=DatSeriell(Jahr([BEA_Wiedervorlage]);12;31);Rechts$(Jahr([BEA_Wiedervorlage]);4) & "/" & Rechts$(Jahr([BEA_Wiedervorlage])+1;2);Wenn(DatSeriell(Jahr([BEA_Wiedervorlage]);8;1)>=[BEA_Wiedervorlage] Und [BEA_Wiedervorlage]>=DatSeriell(Jahr([BEA_Wiedervorlage])-1;12;31);Rechts$(Jahr([BEA_Wiedervorlage])-1;4) & "/" & Rechts$(Jahr([BEA_Wiedervorlage]);2);"-"))

wobei das Feld [BEA_Wiedervorlage] ein Datumsfeld (Format Datum,kurz) ist.
In der Abfrage werden die Daten korrekt ausgerechnet und auch dargestellt. Möchte ich aber in diesem Feld die Abfrage in der korrekt angezeigten Unikatliste manuell filtern, so geht dieses nicht; es wird ebenfalls die Fehlermeldung "Datentypenkonflikt in Kriterienausdruck" in einem Dialog eingeblendet.

Der Aufruf des Berichts erfolgt über ein Formular

Code [Auswählen] Erweitern


    If intEingabe = 1 And Date < DateSerial(lngY, 8, 1) Then
      strFilter = CStr(Right$(lngY - 1, 4) & "/" & Right$(lngY, 2))
      DoCmd.OpenReport "rpt_WIEDERVORLAGE", acViewReport, , "Schuljahr1= " & "'" & strFilter & "'"
    ElseIf intEingabe = 1 And Date >= DateSerial(lngY, 8, 1) Then
      strFilter = CStr(Right$(lngY, 4) & "/" & Right$(lngY + 1, 2))
      DoCmd.OpenReport "rpt_WIEDERVORLAGE", acViewReport, , "Schuljahr1= " & "'" & strFilter & "'"
    End if

Die oben benannte Fehlermeldung erscheint mit der gelb hinterlegten Zeile des DoCmd-Aufrufs.

Meine Fragen:
Warum funktioniert dieses in der DB1 (Gott sei gedankt!) und nicht in der DB2 - obwohl beide DBen dieselbe Struktur haben (Ich habe dies stundenlang(!) überprüft und verglichen)?
Wie kann ich die DB2 "korrigieren", dass auch diese den Datentypenkonflikt nicht mehr anzeigt?

Für Unterstützung danke ich wie immer bereits im Voraus!
gromax

[el_gomero]

Moin,

hab mir das nicht alles durchgelesen, nur mal die Abfrage angesehen. Was soll das $ hinter right? So wurden imo in Urzeiten mal Strings deklariert ...

Egal, hab das rausgenommen und die Abfrage läuft. Einen Bericht habe ich nicht gesehen.

[DF6GL]

Hallo,

die Ursache dürfte in der Verwendung unterschiedlicher Acc-Versionen liegen und damit bei "gebrochenen" Verweisen.....


1) Öffnen den VBA-Editor und korrigiere dort die "nicht vorhandenen" Verweise.
2) Starte die DB neu.
3) Entferne im Abfrageentwurf in der SQL-Ansicht die Eckklammern bei  "[Rechts$]".
4) Führe die Abfrage aus.

[gromax]

Hallo Franz, hallo el_gomero,

vielen Dank für Eure Unterstützung! Leider bin ich nicht weiter gekommen; das Zeichen $ hat keine Auswirkungen - die Abfrage lief ja bereits, bis dass eben in der berechneten Spalte 'Schuljahr1' keine manuelle Filterung möglich ist.

Die Schritte, die Franz mir aufgezeigt hat, habe ich nachvollzogen, ohne dass sich der Datentypenkonflikt aufgelöst hätte.

Nachdem ich heute die neue DB-Version an der aktuellen DB mit den realen Daten eingepflegt habe, lässt sich dieser Bericht auch mit den "echten" Daten nicht mehr öffnen (auch Datentypenkonflikt!!) - jetzt habe ich ein echtes Problem.

Wenn Ihr weitere Ideen habt, nur zu.

Viele Grüße
gromax

[el_gomero]

Hallo,

zum einen hab ich dir eine lauffähige Version hochgeladen - übersehen?
zum anderen hat Franz dir erklärt, was ich vergessen hatte. Die Verweise mussten angepasst werden, weil zB auf meiner Maschine Office10 läuft und die referenzierten Outlook13 und Word13 nicht kannte. Also mal Verweise prüfen.

[gromax]

Hallo Jürgen,

Deine Datei habe ich tatsächlich übersehen - sorry! Aber wenn Du Deine Abfrage ausführst und anschließend in der letzten Spalte [Schuljahr1] den Filter manuell auf das Schuljahr 2015/16 setzen willst, dann erhältst Du doch auch den Datentypenkonflikt - oder etwa nicht?!
Meine Abfrage müsste doch auch durchgelaufen sein.

Die Hinweise von Franz habe ich natürlich abgearbeitet. Tatsächlich habe ich die DB mit Access 2013 entwickelt, anschließend aber die Verweise gelöscht und auf einem anderen Rechner mit Access 2010 wieder eingerichtet, ehe ich die DB an meinem Arbeitsplatz wieder aufgespielt habe.

Kann man die Gleichheit bzw. Durchgängigkeit der Datentypen nicht irgendwie erzwingen?
In meiner Verzweiflung habe ich die Dateneingaben in [BEA_Wiedervorlage] durch 'Format([BEA_Wiedervorlage];"tt.mm.jjjj")' erzwungen, aber das brachte auch nichts.

Der Verzweiflung zweiter Teil; ich habe im aufrufenden VBA-Code des Formulars
mit CStr-Funktion gearbeitet, aber auch ohne Erfolg:

Code [Auswählen] Erweitern


If intEingabe = 1 And Date < DateSerial(lngY, 8, 1) Then
strFilter = CStr(Right(lngY - 1, 4) & "/" & Right(lngY, 2))
strFilter = CStr(strFilter)
DoCmd.OpenReport "rpt_WIEDERVORLAGE", acViewReport, , "Schuljahr1= " & "'" & strFilter & "'"


Jetzt bin ich am Untergehen und um jeden Rettungsring dankbar.

Viele Grüße
gromax

[el_gomero]

Hallo gromax,

Schritt für Schritt ...

• don't panic
  

• Kann man die Gleichheit bzw. Durchgängigkeit der Datentypen nicht irgendwie erzwingen?

  doch natürlich, es liegt doch an dir als Entwickler welche Datentypen du zuweist und verwendest ...
  
• ein Kriterium hatte ich nicht eingegeben, das hab ich wohl überlesen. Werde das heute abend testen und anpassen
  

[DF6GL]

Hallo,


kann es sein, dass es NULL-"Werte" in BEA_Wiedervorlage  gibt?


versuche, um dieses Feld die NZ()-Funktion zu legen:

..........& "/" & Rechts(Jahr(nz([BEA_Wiedervorlage];Datum()))+1;2);...............

[el_gomero]

Hallo,

@ Franz
die Null-Werte wurden in der Abfrage per Kriterium ausgeschlossen.

Es liegt wohl daran, dass im Ausdruck ein Operator (/) benutzt wird. Ich hab das mal auf die Schnelle lauffähig gemacht, indem ich das Zeichen durch ein unverfängliches (_) ersetzt habe. Wobei mir nicht klar ist, warum beim Schuljahr immer das Folgejahr angehangen wird. Schon klar, dass ein Schuljahr nicht gleich Kalenderjahr ist und ins Folgejahr läuft. Es reicht aber das Beginnjahr anzugeben, der Rest ergibt sich doch. Wenn du das berücksichtigen würdest, wäre auch dein Ausdruck nicht so lang.

Ich hab mir die db nicht groß angeschaut, aber mit den vielen Feldern je Tabelle wäre vllt auch das Datenmodell auf den Prüfstand zu stellen.

[DF6GL]

Hi,

nun, ich glaube, dass, bevor ein solches Kriterium greift, die Wenn-Bedingung (komplett, also dann und sonst-Teil) greift und für die Abfrage-Spalte keinen durchgängigen String-Datentyp generiert.

Habe es aber nicht getestet.

Statt das "Schuljahr1" in der Abfrage direkt zu berechnen, könnte diese in eine Public-Funktion mit Datentyp String ausgelagert werden. Dabei könnte auf diesen Wenn-Moloch ganz verzichtet werden.

[el_gomero]

@ Franz

in die Richtung hatte ich auch zuerst gedacht, da es aber mit dem Unterstrich funktioniert scheint das nicht zu greifen. Aber mit dem Moloch geb ich dir Recht - hab ja schon im post darauf hingewiesen, dass das sicher einfacher abzufackeln wäre und es dann gar nicht erst zu Problemen käme. Aber jeder hat ja mal Anfängerfehler gemacht 

[MaggieMay]

Hallo,

Es liegt wohl daran, dass im Ausdruck ein Operator (/) benutzt wird.

nein, ganz sicher nicht, denn der Schrägstrich befindet sich innerhalb eines Strings und nicht in einem "Ausdruck".

Einen Datentypenkonflikt erhalte ich - nach Bereinigung der von Franz erwähnten Fehlerquellen (fehlende - und übrigens in dieser Test-DB völlig überflüssige! - Verweise sowie das daraus resultierende Problem mit der falschen Klammerung der "Rechts$"-Funktion) - übrigens nicht. Muss wohl an den Daten liegen...


Nachtrag:

Möchte ich aber in diesem Feld die Abfrage in der korrekt angezeigten Unikatliste manuell filtern, so geht dieses nicht

Sorry, das hatte ich völlig übersehen, das Filtern klappt tatsächlich nicht!

[el_gomero]

Hallo Maggie,

nein, ganz sicher nicht, denn der Schrägstrich befindet sich innerhalb eines Strings und nicht in einem "Ausdruck".

Der Meinung war ich zunächst auch, es kam aber die besagte Fehlermeldung. Mit dem Unterstrich funktioniert es. Ist vllt wieder mal diese "verschlimmbesserte Intelligenz" von Access, die trotz explizierter String-Formatierung Zahlen und eine Berechnung vermutet. Das mit den Verweisen hatte ich bereits gestern korrigiert.

[MaggieMay]

Hallo Jürgen,

ja, du hast wohl recht (s.a obigen Nachtrag), das muss wohl tatsächlich an einer verborgen agierenden, fehlgeleiteten "Intelligenz" von Access liegen. 

[DF6GL]

Hallo,




Habe das noch mal angesehen...

das "_" - Zeichen geht aber auch nicht beim "=" -  Operator


z. B. Kriterium:  "2015_3"


Wenn wie im Beispiel der Like-Operator (Wie "2015*") eingesetzt wird, gibt es keine Fehlermeldung.

Werden die beiden DS mit leerem "BEA_Wiedervorlage"-Feld aus der DB gelöscht, klappt es auch mit dem Nachbarn, egal ob "/" oder  "_" in der Berechnung, resp.  im  Kriterium (mit "=" -Operator) verwendet wird.   



Bei Einsatz der NZ-Funktion funktioniert  es auch bei DS mit leerem "BEA_Wiedervorlage"-Feld:

Code [Auswählen] Erweitern

Schuljahr1:
Wenn(DatSeriell(Jahr(Nz([BEA_Wiedervorlage];0));8;1)<Nz([BEA_Wiedervorlage];0)
Und Nz([BEA_Wiedervorlage];0)<=DatSeriell(Jahr(Nz([BEA_Wiedervorlage];0));12;31)
;Rechts(Jahr(Nz([BEA_Wiedervorlage];0));4) & "/" & Rechts(Jahr(Nz([BEA_Wiedervorlage];0))+1;2);Wenn(DatSeriell(Jahr(Nz([BEA_Wiedervorlage];0));8;1)>=Nz([BEA_WIEDERVORLAGE];0) Und Nz([BEA_Wiedervorlage];0)>=DatSeriell(Jahr(Nz([BEA_Wiedervorlage];0))-1;12;31);Rechts(Jahr(Nz([BEA_Wiedervorlage];0))-1;4) & "/" & Rechts(Jahr(Nz([BEA_Wiedervorlage];0));2);" "))


(Sorry für die Unformatierung.  Meine Faulheit..  )



Da ist nix Mystisches..


Die verwendeten Funktionen können mit NULL nicht umgehen, bzw. liefern NULL zurück, das eben nicht mit einem String verglichen werden kann.
Zudem gibt die Anwendung einer String-Funktion auf einen numerischen Wert   (  Rechts(Jahr(....))  )   Anlass zur Sorge und erfordert viel Vertrauen in die Access-interne (SQL-interne?) Datentypen-Konvertierung.