Fehler 3085 in Abfrage - Undefinierte Funktion 'Nz' in Ausdruck - Lösung

[Dietmar Thesing]

Liebe ExpertInnen,

vor einiger Zeit hatte ich dasselbe Problem schon einmal angesprochen:
http://groups.google.de/group/microsoft.public.de.access/browse_frm/thread/ff4a864890c0f3c2/8cb8547bd7a1087a?hl=de#8cb8547bd7a1087a

Inzwischen ist der Fehler auf zwei Systemen (siehe unten) schon wieder
aufgetaucht.

Hier kurz zusammengefasst:
In einer Abfrage ist die Nz-Funktion eingebaut und wirft obigen
Fehler.
FE und BE sind MDEs, installiert mit SageKey MSI-Wizard 2002, Runtime
2002.
Der übliche Hinweis ist, dass es an den Verweisen liegt. Es sind aber
nur noch die Standardverweise auf VBA, Accesss und DAO drin. Die
Verweise sind auch in Ordnung, sagt jedenfalls der inzwischen
eingebaute Verweischecker.

Damals aufgetreten auf:
Windows XP, Office 2003 SP3
Die Lösung war etwas unklar.

Jetzt bei:
Windows Vista Ultimate x64 SP1 Deutsch
Office 2007 SP1 Deutsch
Windows Update aktueller Stand

Windows XP Pro SP3 Englisch
Office 2007 SP1 Englisch
Windows Update aktueller Stand

Auf meinen VMs konnte ich den Fehler bisher nicht nachstellen.
Auch nicht mit Vista Ultimate x32,
Office 2007 (Testversion), SP 1.

Lösung Teil 1:
Das SP3 für die *deutsche* Access-Runtime 2002 muss extra über die
Install.ini installiert werden. Das Häkchen im Wizard für das SP3
funktioniert nur bei englischen Runtimes. Die deutsche Version ist
hier erhältlich:
Http://www.microsoft.com/office/orkarchive/2003locddl.htm
(Die Datei Art2002Sp3-kb834693-fullfile-deu.exe
habe ich in den Ordner Files kopiert)

Angehängt an die Install.ini:

[EXTRA_INSTALLS]
INSTALL0=<INST>\files\Art2002Sp3-kb834693-fullfile-deu.exe
CMDLINE0=/q
WAIT1=TRUE

Lösung Teil 2:
Der Nz-Fehler kommt nach dem SP3 immer noch - aber über das
Windows-Update -> Microsoft Update wird jetzt eine Reihe von Updates
für Office XP angeboten (Siehe unten) (Es war auf dem Vista-System
kein Office XP installiert, nur die Runtime). Wenn die installiert
werden, ist der Nz-Fehler weg.

Lösung Teil 3:
Sicherheitshalber habe ich dann noch eine eigene Nz-Funktion
eingebaut, wie Josef es im o.g. Thread beschrieben hat:
Public Function Nz(varWert As Variant, varWertWennNull As Variant) As
Variant
Nz = Access.Nz(varWert , varWertWennNull )
End Function

Leider habe ich zu wenig Ahnung, am liebsten würde ich diese Updates
auch noch mit auf die Installations-CD packen, aber das kostet
langwierige Tests - ich weiß ja nicht, welche davon notwendig sind und
welche nicht und wie sie sich auf den unterschiedlichen Systemen
verhalten.

Gruß
Dietmar

---------------------------------------------------------------------------
Liste der Dateien bzw. die zugehörigen KB-Artikel, die vom
automatischen Update auf Vista angeboten wurden:

Oben genannte Datei ist vom 9.3.2004
http://support.microsoft.com/kb/834693/de

18.10.2005
http://support.microsoft.com/?kbid=904018

13.02.2007
http://support.microsoft.com/?kbid=920816

12.02.2008
http://support.microsoft.com/?kbid=944423

11.03.2008
http://support.microsoft.com/?kbid=932031

12.08.2008
http://support.microsoft.com/?kbid=955440

09.09.2008
http://support.microsoft.com/?kbid=953405

14.10.2008
http://support.microsoft.com/?kbid=956464

[Henry Habermacher]

Hallo Dietmar

Post by Dietmar Thesing
Liebe ExpertInnen,
http://groups.google.de/group/microsoft.public.de.access/browse_frm/thread/ff4a864890c0f3c2/8cb8547bd7a1087a?hl=de#8cb8547bd7a1087a
Inzwischen ist der Fehler auf zwei Systemen (siehe unten) schon wieder
aufgetaucht.

Und glaubst Du immer noch nicht, dass es an den Verweisen gemäss FAQ 7.1
liegt? Hast Du denn inzwischen auf Late Binding umgestellt?

Gruss
Henry

[Dietmar Thesing]

Hallo Henry,

Post by Henry Habermacher
Hallo Dietmar

Post by Dietmar Thesing
Liebe ExpertInnen,
vor einiger Zeit hatte ich dasselbe Problem schon einmal
http://groups.google.de/group/microsoft.public.de.access/browse_frm/thread/ff4a864890c0f3c2/8cb8547bd7a1087a?hl=de#8cb8547bd7a1087a
Inzwischen ist der Fehler auf zwei Systemen (siehe unten) schon wieder
aufgetaucht.

Und glaubst Du immer noch nicht, dass es an den Verweisen gemäss FAQ
7.1 liegt? Hast Du denn inzwischen auf Late Binding umgestellt?
Der übliche Hinweis ist, dass es an den Verweisen liegt. Es sind aber
nur noch die Standardverweise auf VBA, Accesss und DAO drin. Die
Verweise sind auch in Ordnung, sagt jedenfalls der inzwischen
eingebaute Verweischecker.

Es sind wirklich nur noch die drei Verweise drin!
Deshalb hab ich das ja so ausführlich noch mal gepostet.

Gruß
Dietmar

[Henry Habermacher]

Hallo Dietmar

Post by Dietmar Thesing

Post by Henry Habermacher
Und glaubst Du immer noch nicht, dass es an den Verweisen gemäss FAQ
7.1 liegt? Hast Du denn inzwischen auf Late Binding umgestellt?
Der übliche Hinweis ist, dass es an den Verweisen liegt. Es sind aber
nur noch die Standardverweise auf VBA, Accesss und DAO drin. Die
Verweise sind auch in Ordnung, sagt jedenfalls der inzwischen
eingebaute Verweischecker.

Es sind wirklich nur noch die drei Verweise drin!
Deshalb hab ich das ja so ausführlich noch mal gepostet.

Der Fehler, den Du siehst, kommt aber eigentlich nur bei fehlerhaften
Verweisen vor.
Hast Du mal versucht, beim Start der Anwendung die References Collection auf
isBroken hin zu untersuchen? Falls da eine diesen Status hat, dann sind es
die Verweise. Dann ist bei der Installation einer der Komponenten (evt. DAO)
was schief gelaufen. In diesem Fall sollte eine neu-registrierung der DAO
DLL weiterhelfen.

Gruss
Henry

[Dietmar Thesing]

Hallo Henry,

Post by Henry Habermacher
Hallo Dietmar

Post by Dietmar Thesing

Post by Henry Habermacher
Und glaubst Du immer noch nicht, dass es an den Verweisen gemäss FAQ
7.1 liegt? Hast Du denn inzwischen auf Late Binding umgestellt?
Der übliche Hinweis ist, dass es an den Verweisen liegt. Es sind aber
nur noch die Standardverweise auf VBA, Accesss und DAO drin. Die
Verweise sind auch in Ordnung, sagt jedenfalls der inzwischen
eingebaute Verweischecker.

Es sind wirklich nur noch die drei Verweise drin!
Deshalb hab ich das ja so ausführlich noch mal gepostet.

Der Fehler, den Du siehst, kommt aber eigentlich nur bei
fehlerhaften Verweisen vor.

Ja, eigentlich, aber ...

Post by Henry Habermacher
Hast Du mal versucht, beim Start der Anwendung die References
Collection auf isBroken hin zu untersuchen?

... genau das macht doch der Verweischecker, ich glaube von Terry
Kreft? Die waren laut Aussage des Testers voll in Ordnung, hat er mir
auch ausführlich aufgeschrieben, ich hab's mal in den Anhang gepackt.

Post by Henry Habermacher
Falls da eine diesen Status hat, dann sind es die Verweise. Dann ist
bei der Installation einer der Komponenten (evt. DAO) was schief
gelaufen. In diesem Fall sollte eine neu-registrierung der DAO DLL
weiterhelfen.

Leuchtet ja grundsätzlich ein, aber ich sehe nicht, dass es die
Verweise sind. Die Nz-Funktion gehört ja auch zu Access und scheint
nur in der Abfrage Probleme zu machen - vorher, beim Registrieren usw.
ist sie auch schon mehrfach benutzt worden.

Aber, wie geschrieben, nach dem Einspielen der Updates für die Runtime
ist das Problem behoben.

Gruß
Dietmar

[Henry Habermacher]

Hallo Dietmar

Post by Dietmar Thesing
Leuchtet ja grundsätzlich ein, aber ich sehe nicht, dass es die
Verweise sind. Die Nz-Funktion gehört ja auch zu Access und scheint
nur in der Abfrage Probleme zu machen - vorher, beim Registrieren usw.
ist sie auch schon mehrfach benutzt worden.

Wenn Du den vorzüglichen Vortrag von Thomas Moeller an der vorletzen AEK
gelesen hättest, wüsstest Du, dass die Verweisprobleme nicht dort zuschlagen
(müssen), wo sie in die Hose gehen. Das hängt vom Scope ab.

In Abfragen selber gehört - engegen Deiner Aussage - Nz() nicht zu Access,
sondern kommt aus der Jet Engine, welche selber die gleichen Funktionen
(teilweise nicht komplett identisch) implementiert hat. Nz() ist also nicht
immer aus Access, wenn es in Abfragen verwendet wird, ist es in Jet
implementiert.

Kontrolliere mal die Jet und DAO Versionen dieser Maschinen. Registriere die
Jet und DAO Libraries neu.

Gruss
Henry

[Dietmar Thesing]

Hallo Henry,

Post by Henry Habermacher
Hallo Dietmar

Post by Dietmar Thesing
Leuchtet ja grundsätzlich ein, aber ich sehe nicht, dass es die
Verweise sind. Die Nz-Funktion gehört ja auch zu Access und scheint
nur in der Abfrage Probleme zu machen - vorher, beim Registrieren usw.
ist sie auch schon mehrfach benutzt worden.

Wenn Du den vorzüglichen Vortrag von Thomas Moeller an der vorletzen
AEK gelesen hättest, wüsstest Du, dass die Verweisprobleme nicht
dort zuschlagen (müssen), wo sie in die Hose gehen. Das hängt vom
Scope ab.

Das war mir schon so weit klar, ..

Post by Henry Habermacher
In Abfragen selber gehört - engegen Deiner Aussage - Nz() nicht zu
Access, sondern kommt aus der Jet Engine, welche selber die gleichen
Funktionen (teilweise nicht komplett identisch) implementiert hat.
Nz() ist also nicht immer aus Access, wenn es in Abfragen verwendet
wird, ist es in Jet implementiert.

... das nicht, danke für den Hinweis. Das heißt aber wohl, dass die
eigene Nz-Funktion helfen müsste?

Post by Henry Habermacher
Kontrolliere mal die Jet und DAO Versionen dieser Maschinen.
Registriere die Jet und DAO Libraries neu.

Da bin ich hoffnungslos überfordert, obwohl nur Dilettant, würde ich
es bei mir ja vielleicht noch hinkriegen, aber noch ist es mir nicht
gelungen, den Nz-Fehler auf meinen VMs nachzustellen. Er passiert nur
auf manchen Computern, und die stehen irgendwo in der Republik.

Aber wenn Du Recht hast - ich vermute dann eher die Jet:
Wird dieses Neuregistrieren eventuell von den automatischen Updates
gemacht? Es muss ja einen Grund haben, dass der Fehler nach den
XP-Runtime-Updates (bei den Updates in Vista ohne Office XP als Office
XP aufgeführt) nicht mehr auftaucht.

Danke sehr,
Gruß
Dietmar

[Josef Poetzl]

Hallo!

Post by Henry Habermacher
In Abfragen selber gehört - engegen Deiner Aussage - Nz() nicht zu Access,
sondern kommt aus der Jet Engine, welche selber die gleichen Funktionen
(teilweise nicht komplett identisch) implementiert hat. Nz() ist also nicht
immer aus Access, wenn es in Abfragen verwendet wird, ist es in Jet
implementiert.

Das sind Dinge, die ich mir nie richtig merke.
Bei iif weiß ich es, aber ist Nz() auch in Jet enthalten?
Wenn ich eine SQL-Anweisung außerhalb von Access (z. B. unter
Excel-VBA) ausführe, kann ich nämlich Nz in der SQL-Anweisung nicht
nutzen. Daraus würde ich schließen, dass Nz in Jet nicht enthalten
ist.

mfg
Josef

[Thomas Möller]

Hallo Josef,

Post by Josef Poetzl

Post by Henry Habermacher
In Abfragen selber gehört - engegen Deiner Aussage - Nz() nicht zu Access,
sondern kommt aus der Jet Engine, welche selber die gleichen Funktionen
(teilweise nicht komplett identisch) implementiert hat. Nz() ist also nicht
immer aus Access, wenn es in Abfragen verwendet wird, ist es in Jet
implementiert.

Das sind Dinge, die ich mir nie richtig merke.
Bei iif weiß ich es, aber ist Nz() auch in Jet enthalten?
Wenn ich eine SQL-Anweisung außerhalb von Access (z. B. unter
Excel-VBA) ausführe, kann ich nämlich Nz in der SQL-Anweisung nicht
nutzen. Daraus würde ich schließen, dass Nz in Jet nicht enthalten
ist.

ich konnte mich erinnern, dass es da einen Blog gibt, der sich mit
diesem Thema beschäftigt - nur der Namen wollte mir nicht einfallen. Ist
ja auch kein Wunder: ;-)
http://brenreyn.blogspot.com/2004/04/conditional-expressions-in-jet-sqlaka_22.html
(Link in einer Zeile)

CU

[Karl Donaubauer]

Hallo, Josef!

Post by Josef Poetzl

Post by Henry Habermacher
In Abfragen selber gehört - engegen Deiner Aussage - Nz() nicht zu
Access, sondern kommt aus der Jet Engine, welche selber die gleichen
Funktionen (teilweise nicht komplett identisch) implementiert hat. Nz()
ist also nicht immer aus Access, wenn es in Abfragen verwendet wird, ist
es in Jet implementiert.

Das sind Dinge, die ich mir nie richtig merke.
Bei iif weiß ich es, aber ist Nz() auch in Jet enthalten?
Wenn ich eine SQL-Anweisung außerhalb von Access (z. B. unter
Excel-VBA) ausführe, kann ich nämlich Nz in der SQL-Anweisung nicht
nutzen. Daraus würde ich schließen, dass Nz in Jet nicht enthalten
ist.

Joo, Nz() gibt's nur in der Access-Bibliothek, nicht in JET.
Das hatten wir schon öfter, z.B. hier:
http://groups.google.com/group/microsoft.public.de.access/browse_frm/thread/18ba8ce98450db15/c9c8927192b28a03

Ich finde schon wieder (oder noch immer?) keine brauchbare Liste,
welche Funktionen in JET verfügbar sind, aber man kann z.B. den
DAO-Test in Excel aus http://support.microsoft.com/kb/209864/en-us
veranstalten. Mit Iif() kein Problem, mit Nz() 3085.

[André Minhorst]

Hallo zusammen!

Post by Karl Donaubauer
[...]
Ich finde schon wieder (oder noch immer?) keine brauchbare Liste,
welche Funktionen in JET verfügbar sind, aber man kann z.B. den
DAO-Test in Excel aus http://support.microsoft.com/kb/209864/en-us
veranstalten. Mit Iif() kein Problem, mit Nz() 3085.

Vielleicht gibt es noch eine weitere Möglichkeit: Man gibt einfach den
Ausdruck in kleinen Buchstaben in ein Feld des Abfrageentwurfs ein (etwa
Test: nz("lala","")) und schaut, ob der Abfrage-Editor den Funktionsnamen
mit Großbuchstaben versieht (also Nz statt nz) oder, wenn beispielsweise
die deutsche Version verwendet wird, direkt den deutschen Funktionsnamen
einsetzt. In dem Fall handelt es sich um eine der Funktionen der Jet
Expression Services.

Mag das jemand bestätigen/widerlegen?

Ciao
André

[Josef Poetzl]

Hallo!

Post by André Minhorst

Post by Karl Donaubauer
[...]
Ich finde schon wieder (oder noch immer?) keine brauchbare Liste,
welche Funktionen in JET verfügbar sind, aber man kann z.B. den
DAO-Test in Excel aus http://support.microsoft.com/kb/209864/en-us
veranstalten. Mit Iif() kein Problem, mit Nz() 3085.

Eine weitere Variante ist das Öffnen eines ADODB-Recordset. Das
funktioniert dann auch innerhalb von Access-VBA.

Post by André Minhorst
Vielleicht gibt es noch eine weitere Möglichkeit: Man gibt einfach den
Ausdruck in kleinen Buchstaben in ein Feld des Abfrageentwurfs ein (etwa
Test: nz("lala","")) und schaut, ob der Abfrage-Editor den Funktionsnamen
mit Großbuchstaben versieht (also Nz statt nz) oder, wenn beispielsweise
die deutsche Version verwendet wird, direkt den deutschen Funktionsnamen
einsetzt. In dem Fall handelt es sich um eine der Funktionen der Jet
Expression Services.

Das wäre zu schön, um wahr zu sein. :-)

eval("1+2")
Im Abfrageentwurf unter AcXP wird daraus Auswerten("1+2")
In Jet ist Eval(..) aber nicht enthalten.

mfg
Josef

[Henry Habermacher]

Hallo Karl

Post by Karl Donaubauer
Joo, Nz() gibt's nur in der Access-Bibliothek, nicht in JET.
http://groups.google.com/group/microsoft.public.de.access/browse_frm/thread/18ba8ce98450db15/c9c8927192b28a03

Und auch ich bin wieder reingefallen...

Danke für die Richtigstellung.

@Dietmar: Statt Nz() kannst Du in der Abfrage

SELECT Iif(IsNull([DeinFeld]), 'Null-Ersatzwert', [DeinFeld]) AS Irgendwas
FROM
...

verwenden. Da wird dann Nz() nicht aus Access heraus aufgerufen sondern die
Jet internen Funktionen Iif() und IsNull().

Ich kann mir aber immer noch nicht erklären, wieso das bei Dir nicht richtig
läuft. Da muss irgendwas nicht suaber installiert sein.
Dabei fällt mir allerdings nun auf: Du istallierst mit SageKey die Access
Runtime 2002. Und auf der gleichen Maschine sind noch neuere Office
Versionen installiert. Ich gehe davon aus, dass mit Office auch irgendwas
mit DAO/Jet installiert wird, je nach Optionen. Es könnte schon sein, dass
damit die Installation der Access Runtime 2002 nicht mehr ganz sauber ist.
Geht vielleicht etwas mit der Installation des SP3 für Access 2002 schief?
Da die Fehler nach der Installation der Updates für Office XP weg sind, gehe
ich davon aus, dass diese Installation die Access RT repariert.
Bezüglich nicht notwendiger Updates. Diese sollten eigentlich automatisch
nicht installiert werden, wenn diese nicht nötig sind. Du kannst diese also
schon auf die Installations CD packen.

Gruss
Henry

[Dietmar Thesing]

Hallo Henry,
danke,

Post by Henry Habermacher
Hallo Karl

Post by Karl Donaubauer
Joo, Nz() gibt's nur in der Access-Bibliothek, nicht in JET.
http://groups.google.com/group/microsoft.public.de.access/browse_frm/thread/18ba8ce98450db15/c9c8927192b28a03

Und auch ich bin wieder reingefallen...
Danke für die Richtigstellung.
@Dietmar: Statt Nz() kannst Du in der Abfrage
SELECT Iif(IsNull([DeinFeld]), 'Null-Ersatzwert', [DeinFeld]) AS Irgendwas
FROM
...
verwenden. Da wird dann Nz() nicht aus Access heraus aufgerufen
sondern die Jet internen Funktionen Iif() und IsNull().

Ja, klar - ich wollte da nur ursprünglich nicht dran, weil mir nicht
klar war, ob es nur die Nz-Funktion war, die die Probleme bereiten
könnte, oder auch anderes nicht funktioniert. Wenn ich das Problem bei
mir hätte nachstellen können, wäre das Ganze einfacher gewesen.

Spricht denn etwas gegen die Lösung von Josef, also die Nz-Funktion
mit einer eigenen zu überschreiben? Die hat den kleinen Vorteil, dass
ich nicht alle Abfragen durchsuchen und ändern muss. (Manche sind so
kompliziert, dass ich Änderungen immer erst im Texteditor machen muss,
weil Access so komische Klammern und Punkte setzt, dass die Abfrage
nach dem zweiten Abspeichern nicht mehr funktioniert.)

Post by Henry Habermacher
Ich kann mir aber immer noch nicht erklären, wieso das bei Dir nicht
richtig läuft. Da muss irgendwas nicht suaber installiert sein.
Dabei fällt mir allerdings nun auf: Du istallierst mit SageKey die
Access Runtime 2002. Und auf der gleichen Maschine sind noch neuere
Office Versionen installiert. Ich gehe davon aus, dass mit Office
auch irgendwas mit DAO/Jet installiert wird, je nach Optionen. Es
könnte schon sein, dass damit die Installation der Access Runtime
2002 nicht mehr ganz sauber ist. Geht vielleicht etwas mit der
Installation des SP3 für Access 2002 schief?

Ist mir natürlich auch passsiert - aber das Problem bestand auch nach
SP3. Ganz erklärbar ist das nicht, weil die neueren Office-Version(en)
ja schon vorher drauf waren.
Andererseits weiß ich natürlich (Dilettant) auch nicht, was die
SageKey-Exe so alles macht. Auf der Homepage (Supportbereich,
geschützt) ist ein Hinweis, dass es ohne SP3 bei der 2002er Version zu
nicht näher definierten Problemen kommen kann.

Post by Henry Habermacher
Da die Fehler nach der Installation der Updates für Office XP weg
sind, gehe ich davon aus, dass diese Installation die Access RT
repariert.

Da kann ich prinzipiell auch mit leben - ins Begleitheft kommt jetzt
sicherheitshalber auch die Empfehlung, nach der Installation das
Windows-Update aufzurufen.

Post by Henry Habermacher
Bezüglich nicht notwendiger Updates. Diese sollten eigentlich
automatisch nicht installiert werden, wenn diese nicht nötig sind.
Du kannst diese also schon auf die Installations CD packen.

Danke für den Hinweis, werd ich also noch überlegen und testen müssen.

Vielen Dank, das war hilfreich,
Gruß
Dietmar

[Jens Schilling]

Hallo, Dietmar

(Manche sind so kompliziert, dass ich Änderungen immer erst im Texteditor
machen muss, weil Access so komische Klammern und Punkte setzt, dass die
Abfrage nach dem zweiten Abspeichern nicht mehr funktioniert.)

Wenn Du die Abfrage in der SQL-Ansicht speicherst, wird diese auch so wieder
geöffnet; das würde Dir das Öffnen eines Texteditores sparen.

Gruss
Jens

[Dietmar Thesing]

Hallo Jens,

Post by Jens Schilling
Hallo, Dietmar

(Manche sind so kompliziert, dass ich Änderungen immer erst im
Texteditor machen muss, weil Access so komische Klammern und Punkte
setzt, dass die Abfrage nach dem zweiten Abspeichern nicht mehr
funktioniert.)

Wenn Du die Abfrage in der SQL-Ansicht speicherst, wird diese auch
so wieder geöffnet; das würde Dir das Öffnen eines Texteditores
sparen.

Ja, stimmt grundsätzlich, mache ich auch oft - aber beim 2. Speichern
wirft Access trotzdem manchmal unerwünschte Zeichen (Punkte und eckige
Klammern) rein (das heißt glaube ich Optimierung). Hatten wir hier
auch mal als Thread, ist etwas filigran.

Gruß
Dietmar

[Thomas Oberdörfer]

Moin die Herren... ;o)

Also, ich will auch mal ein Statement dazu abgeben, irgendwelche
Vorträge oder so lasse ich mal ganz außer Acht... ;o)

1) Ein Fehler bei Verwendung von Nz(), Left(), Mid() etc. tritt in der
Regel auf, wenn irgendetwas mit den Verweisen nicht stimmt. Deswegen
o.g. Vorgehensweisen und Tipps befolgen!

2) Den gleichen (oder denselben?) Fehler wie von Dietmar beschrieben,
hatte ich auch schon mehrmals. Das hatte dann nix mit Verweisproblemen
zu tun. Der Fehler, dass die Funktion Nz() unbekannt sei (und auch nur
die Funktion Nz(), andere verweisproblemtypischen Funktionen wie Left
(), Mid(), etc. wurden nicht angemeckert!) tritt scheinbar willkürlich
auf. Den wirklichen Grund kann ich auch nicht sagen, jedoch war der
Fehler "verschwunden", wenn man die Datenbank komprimierte. Eventuell
hat da irgendetwas nur nen Knacks?

3) Die Fehlermeldungen sind unterschiedlich! Bei Referenzproblemen
wird eine andere Fehlermeldung ausgebeben, als bei der von Dietmar und
mir festgestellten einfachen Meldung "Funktion unbekannt"!

Wie gesagt, ich habe keine Ahnung, warum das auftritt, hat auch mit
Servicepacks oder Versionen nix zu tun, hatte das wie gesagt auch
schon ein paar Mal unabhängig von der Access-Version und vom SP-Stand!
Nach einem Komprimieren/Reparieren war alles wieder gut.

Gruss
Thomas

[Thomas Möller]

Hallo Dietmar,

Spricht denn etwas gegen die Lösung von Josef, also die Nz-Funktion mit
einer eigenen zu überschreiben? Die hat den kleinen Vorteil, dass ich
nicht alle Abfragen durchsuchen und ändern muss.

ob bzw. dass eine solche Lösung funktioniert kannst Du wie folgt testen:
Du erstellst Dir eine eigene Funktion mit den Namen Nz, die die selben
Parameter erwartet, wie die Originalfunktion. Diese Funktion speicherst
Du in einem Modul in Deiner Datenbank. In der Funktion schreibst Du, für
diesen Test, einfach nur eine MsgBox.


Public Function NZ(Value, ValueIfNull)

MsgBox "Meine NZ-Funktion"

End Function


Jetzt erstellst Du eine Abfrage, die nur wenige DS liefert. Darin
verwendest Du die Nz-Funktion. Für jeden DS wird jetzt die MsgBox einmal
aufgerufen.

Mit einer solchen Lösung beseitigst Du IMHO nur ein Symptom. Die
eigentliche Ursache des Problems bleibt weiter unklar.

CU

[Dietmar Thesing]

Hallo Thomas,

Post by Thomas Möller
Hallo Dietmar,

Post by Dietmar Thesing
Spricht denn etwas gegen die Lösung von Josef, also die Nz-Funktion
mit einer eigenen zu überschreiben? Die hat den kleinen Vorteil,
dass ich nicht alle Abfragen durchsuchen und ändern muss.

...

Kann ich ja eben nicht - das Problem taucht doch auf meinen VMs und
Computern nicht auf, da funktioniert beides. ;-(

Post by Thomas Möller
Mit einer solchen Lösung beseitigst Du IMHO nur ein Symptom. Die
eigentliche Ursache des Problems bleibt weiter unklar.

Da hast Du mit beiden Sätzen Recht.
Der Beitrag von Thomas Oberdörfer war zwar hilfreich, aber leider auch
keine Lösung - noch mal, der Fehler ist mit den Runtime-Updates
behoben, ohne Komprimierung des FE.

Herzlicher Gruß
Dietmar

[Thomas Möller]

Hallo Dietmar,

Post by Dietmar Thesing

Post by Dietmar Thesing
Spricht denn etwas gegen die Lösung von Josef, also die Nz-Funktion
mit einer eigenen zu überschreiben? Die hat den kleinen Vorteil,
dass ich nicht alle Abfragen durchsuchen und ändern muss.

....
Kann ich ja eben nicht - das Problem taucht doch auf meinen VMs und
Computern nicht auf, da funktioniert beides. ;-(

aber Du könntest durch diesen Test sehen, dass Deine selbst geschriebene
NZ-Funktion zum Einsatz kommt. Dort würdest Du dann Befehle verwenden,
die bisher unkritisch sind.

Aber wie schon gesagt: so wird nur das Symptom beseitigt - nicht das
Problem.

CU

[Henry Habermacher]

Hallo Dietmar

Post by Dietmar Thesing
keine Lösung - noch mal, der Fehler ist mit den Runtime-Updates
behoben, ohne Komprimierung des FE.

Wenn es damit behoben ist, dann geht definitiv was mit der Installation der
Anwendung schief. An Deiner Stelle würde ich mal bei Sage nachfragen, ob
dort sowas bekannt ist oder allenfalls mal ein komplett neues Setup mit
SageKey erstellen.

Gruss
Henry

[Dietmar Thesing]

Hallo Josef, Thomas, Karl, ...

ich bin jetzt ein wenig überfordert (die Links habe ich angesehen,
aber mein Englisch ist recht schlecht, gerade im Blick auf das
Computer-Englisch), verstanden habe ich:

Nz ist also nur Access, nicht Jet.
Eine eigene Nz-Funktion (wie in dem Blog bzw. von Dir, Josef) dürfte
also in jedem Falle dem 3085 ein Schnippchen schlagen.

Aber: Mich treibt immer noch um, bzw. ich habe nicht so richtig
verstanden, wieso ich das Problem nicht nachstellen kann und wieso es
(auf anderer Leute Computer, VM und real) mit einem Microsoft Update
behoben ist.

Gruß
Dietmar