Office: (Office 2016) SQL-Unterabfrage

Hallo Forum,

in diesem Beitrag wird über einen neuen Bug in MS Access berichtet und gleichzeitig ein sehr hilfreicher workaround empfohlen.

Ich muss kurzfristig eine existierende Anwendung entsprechend mit einem workaround versehen. In der Datenbank habe ich ein Feld "Prov_Wert", das von dem Bug betroffen ist. Wie in #2 des o. g. Beitrags beschrieben kann ich den Bug umgehen, wenn ich im SQL schreibe:
Code:

Nun habe ich an anderer Stelle aber eine Unterabfrage zur Emittlung des Wertes, und da ist es mir nicht gelungen, den Workaround anzuwenden.
Ich habe versucht:
Code:

 

Moin,
ich würds mal mit
Code:

versuchen.
maike

 

Hallo Maike,

herzlichen Dank für Deinen Input. Leider hat das nicht zum Erfolg geführt. Ich hatte schon beide Versionen probiert, mit der inneren und äußeren Formatangabe. Aber noch nicht mit beiden. Leider bleibt es beim Crash, das Format wird also nicht korrekt erkannt.

Im SQL sieht Deine Version so aus:
Code:

 

Danke für die Blumen *wink.gif* . Aber was das generelle Datentyp-Subquery-Problem angeht, bin ich jetzt am Ende meiner Weisheit ...
Du könntest als Workaround nochmal versuchen, eine gespeicherte Abfrage einzubinden oder DMax() zu verwenden.
maike

 

Hallo Michael O.,

Mit der VBA-Funktion VarType (bzw. im Designer VarTyp) lässt sich das ermitteln, etwa in der Art (doppelte Klammerung ist nötig!):

Prov_Wert_Type: VarTyp( (SELECT ...) )

Die Bedeutung der zurückgegebenen Zahl ist in der Accesshilfe bei VarType zu finden. z. B. 5 = Double, 14 = Decimal usw.

----------

Zu beachten ist auch, dass die CDbl-Funktion keine leeren Tabellenfelder mag (Fehlermeldung). Falls Prov-Wert auch leer sein kann (NULL) oder der Sub-Select keinen Datensatz liefern sollte, dann probier in beiden Fällen mal die Nz-Funktion, etwa in der Art:

Prov_Wert_xx: cdbl( nz( (SELECT top 1 cdbl( nz( Prov_Wert , 0 ) ) AS Prov_Wert_x from PROVISION where PROVISION.ID_KUNDE_ref = GERUEST.ID_KUNDE_ref and Gueltig_ab