SQL Fehler: Die vorbereitete Anweisung mit dem Handle xy ...

Hallo zusammen,

seit dem 10. Mai treten bei einem unserer Kunden diese Fehler auf. Hier ein Beispiel aus dem Ereignisprotokoll eines NST-Servers:
Server instance: NAVServerProd
Tenant ID: default
Session type: RoleTailoredClient
Session ID: 12
User: Domain\Username
Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavSqlException
SuppressMessage: False
SuppressExceptionCreatedEvent: False
FatalityScope: None
Message:
Der folgende SQL-Fehler war nicht erwartet.
Die vorbereitete Anweisung mit dem Handle 4571 wurde nicht gefunden.
SQL-Anweisung:
SELECT "timestamp","Type","No_",.... FROM "NAV2013".dbo."Company$Table 123" WITH(READUNCOMMITTED) WHERE ("Type"=@0 AND "No_"=@1) OPTION(OPTIMIZE FOR UNKNOWN)


Die Fehler treten auf allen NST-Servern auf, aber nicht gleichzeitig. Scheinbar sind immer alle Benutzer eines NST betroffen. Sie bekommen dann eine entsprechende Fehlermeldung angezeigt, können die bestätigen und dann entweder weiterarbeiten, oder sie bekommen die Meldung noch einmal (und noch einmal und noch einmal, und....). Teilweise können die Anwender nicht mehr arbeiten. Melden sie sich dann auf einem anderen NST an, geht es wieder. Nach einiger Zeit verschwindet auch der Effekt wieder - ohne, dass das NST neu gestartet wurde.

Der Fehler taucht nicht täglich auf, manchmal aber mehrere Tage hintereinander. Die Uhrzeiten sind verschieden, und auch die Prozesse der betroffenen Anwender.

Hat das schon mal jemand gehabt und weiß, wie wir das wieder loswerden oder hilfreiche Tipps?

Microsoft hat die Support Anfrage natürlich - mit Hinweis auf den beendeten Mainstream Support - dankend abgelehnt.

Dankeschön
Heinrich

HAllo,

habt ihr irgendwas geändert, Windows- Updates eingespielt? Laufen da irgendwelche Tools, die Aufräumen sollen? Virenscanner?

Das sieht danach aus, als ob da Abfragen, die das System vorbereitet hat, wieder verworfen wurden, bevor das System (SQL-Server) sie wieder nutzen wollte.

Da musst du dir wohl mal einen SQL- Trace anschauen, wann die Abfrage erstellt wurde, und wann Sie verworfen wurde.

Gruß Fiddi

Hallo zusammen,

ich habe das gleiche Problem, seit Mai 2019, allerdings mit NAV 2016.
Es verhindert die erfolgreiche Aktualisierung der per OData auf die Datenbank zugreifenden Power Bi Berichte.
Der SQL Server wurde auch schon aktualisiert und es wurden diverse Einstellungen am Service selbst geändert (DataCacheSize, SQL Command Timeout, ...).
Natürlich wurde auch alles mit den Defaultwerten getestet.

Da der Dienst, von welchem via OData die Daten abgerufen werden, separat läuft, kann ich diesen Problemlos neustarten.
Dies hilft temporär, tritt aber nach kurzer Zeit erneut auf.

An der NAV Version selbst wurde (seit Mai) nichts verändert.

Vielleicht hat ja jemand eine Idee.

Gruß, Bale

Haben das gleiche Problem mit 2018. Wurde auch schon an Microsoft gemeldet. Es soll wahrscheinlich bald ein Hotfix dafür geben. Aber es scheint so, als wenn Microsoft da selber noch nicht ganz sicher ist, das Problem tatsächlich gefunden zu haben.

Hi,
und wir mit Dynamics 2017CU24.
Hat sich MS schon dazu geäußert bzw. hast du schon eine Rückmeldung erhalten?
Danke.

Seit diesem Mittwoch leiden wir auch unter diesem nervigen Phänomen.

Datenbank: NAV 2017 CU 05 (10.00.16177)
Runtime: NAV 2017 CU 11 (10.00.18609)
Auf die Live-Datenbank greifen 10 NST zu. (10 verschiedene virtuellen Maschinen, die nur für NST genutzt werden)
Alle NST werden jede Nacht neu gestartet.
Die Anwender arbeiten über Citrix (8 eigene Maschinen nur für Citrix)
Der SQL-Server ist ebenfalls eine eigenständige Maschine.

Die Handle-Fehler kommen auf verschiedenen NST, jedoch kommt derselbe Handle-Fehler nur auf dem einen NST, während auf einem anderen NST kein oder ein anderer Handle-Fehler die Anwender begrüßt.
Per Debugger kann man (mit etwas Glück) die Programmcode-Stelle ausfindig machen, die den Handle-Fehler auslöst.
So konnte ich z. B. ein IF NOT PurchLine.ISEMPTY THEN BEGIN ausfindig machen.

Teilweise bekommen die Anwender den Handle-Fehler irgendwann im Laufe ihrer Arbeit in NAV, teilweise aber schon direkt beim Versuch, den RTC zu starten (also beim Login).

Folgende Fragen habe ich hierzu:

1. Was ist die Ursache für diese Fehlermeldung?
2. Wo liegt die Ursache? (RTC, NST oder SQL-Server?)
3. Gibt es dazu bereits eine offizielle Lösung? (Update für NAV bzw. SQL-Server)
4. Gibt es einen Workaround? (Leeren einer bestimmten SQL-Tabelle, löschen einer bestimmten Datei im NST-Verzeichnis, ...)

Ich hole diesen Thread nochmal hervor, in der Hoffnung, wenigstens einen Workaround zu erhalten.

Objekte kompilieren, NSTs / SQL-Server neustarten hat bisher nichts gebracht.
Der Handle-Fehler taucht weiterhin sporadisch an immer unterschiedlichen Stellen auf immer unterschiedlichen NSTs auf und verschwindet nach einigen Minuten (ohne dass man etwas an den Objekten, NSTs oder dem SQL-Server gemacht hat) um dann einige Zeit später (Minuten bis Stunden) auf einem anderen NST an einer anderen Stelle wieder einen anderen Anwender zu ärgern.

Wurde auch schon an Microsoft gemeldet. Es soll wahrscheinlich bald ein Hotfix dafür geben. Aber es scheint so, als wenn Microsoft da selber noch nicht ganz sicher ist, das Problem tatsächlich gefunden zu haben.

Hat sich MS schon dazu geäußert bzw. hast du schon eine Rückmeldung erhalten?

Seit diesem Mittwoch leiden wir auch unter diesem nervigen Phänomen.
[...]
Folgende Fragen habe ich hierzu:

1. Was ist die Ursache für diese Fehlermeldung?
2. Wo liegt die Ursache? (RTC, NST oder SQL-Server?)
3. Gibt es dazu bereits eine offizielle Lösung? (Update für NAV bzw. SQL-Server)
4. Gibt es einen Workaround? (Leeren einer bestimmten SQL-Tabelle, löschen einer bestimmten Datei im NST-Verzeichnis, ...)

Wir haben das ebenfalls das selbe Problem bei NAV2013R2.
Allerdings nicht auf allen NSTs. Es betrifft zu 99% die gleiche.

Leider bisher auch noch keine Lösung/Workaround gefunden.
Falls jemand mehr weiß, würden wir uns über einen Tipp freuen.

bei mir was es damals der MARK Befehl, der das immer verursacht hat. Habe das dann über temporäre Tabellen anders gelöst und dann kam der Fehler nicht mehr. Ob MS da jetzt was mit einem neueren CU geändert hat, weiß ich leider nicht, weil das Thema dann für mich erledigt war.

bei mir was es damals der MARK Befehl, der das immer verursacht hat.

Wenn der Fehler wenigstens immer bei demselben Prozess oder vergleichbarem Programmcode auftreten würde, dann könnte man es ja wenigstens auf den C/AL-Code schieben, wie in deinem Fall.
Bei uns tritt es aber an immer anderen Stellen auf, die sogar eine klassisch-saubere Programmierung aufweisen, wie z. B.

Code:

PurchLine.RESET;
PurchLine.SETRANGE("Document Type",PurchLine."Document Type"::Order);
PurchLine.SETRANGE("Document No.",PurchHeader."No.");
IF NOT PurchLine.ISEMPTY THEN BEGIN  // <-- Hier hält der Debugger bei dem Handle-Fehler an
  [...]
END;

Andere Anwender auf anderen NSTs erhalten bei demselben Programmcode keinen Fehler.
Ca. 5-10 Minuten später tritt der Fehler auf dem NST dann auch nicht mehr auf.
Dafür dann irgendwann irgendwoanders auf irgendeinem NST.

Ist der Fehler auf einem NST bei einem Anwender aufgetreten, dann haben auch alle anderen Anwender auf diesem NST bei diesem Programmcode den Handle-Fehler.

Was sagt denn der SQL-Profiler zu dieser Tatsache? Kommt da überhaupt was an?

Unsere bisherigen Recherchen haben ergeben, dass der SQL-Server von diesen Handle-Fehlern gar nichts mitbekommt.

Das NST möchte eine SQL-Abfrage absetzen und bereitet dazu eine Anweisung vor.
Kurz danach möchte das NST diese vorbereitete Anweisung an den SQL-Server abschicken, findet sie aber nicht mehr wieder.

Ich hatte diesbezüglich am Freitag einen Supportfall bei unserem betreuenden Systemhaus eröffnet und bekam noch am Freitag Abend eine Antwort:

In den CU-Beschreibungen zum CU 36 für NAV 2017 gibt es einen Eintrag:
ID: 329273
Title: "Could not find prepared statement with handle 12345 error message is displayed that requires you to restart the relevant NAV service."

Wir werden jetzt ein technisches Update unserer NAV 2017 Umgebung auf das aktuellste CU für NAV 2017 vornehmen und hoffen, dass wir damit das Problem beseitigen können.

Wir hatten für die Tests eine Kopie der Produktiv-Datenbank erstellt und auf einer neu eingerichteten virtuellen Maschine NAV2017 CU 43 installiert (DevClient, RTC, NST).

Dort hatten unsere Consultants und Keyuser intensiv getestet.
Alle Prozesse funktionierten einwandfrei und wir bekamen nicht ein einziges mal den Handle-Fehler.

Also haben wir gestern Abend alle NAV2017-Installationen von CU11 auf CU43 aktualisiert und alle NAV2017-Datenbanken technisch konvertiert, Schema-Synchronisation (With Validation) durchgeführt und in den Produktiv-Datenbanken zusätzlich noch alle Objekte durchkompiliert.

Anschließend wurde in unserer „Hauptdatenbank“ (in der das operative Kerngeschäft läuft) ein Szenarientest durchgeführt, der ebenfalls erfolgreich verlief.

Heute früh dann die Ernüchterung:
Obwohl unsere Datenbanken jetzt alle technisch auf CU43 (Build 30284) laufen (und damit die Korrektur des CU36 enthalten), bekommen wir plötzlich wieder die Fehlermeldung

The following SQL error was unexpected:
Die vorbereitete Anweisung mit dem Handle 10400 wurde nicht gefunden.

Scheinbar hat die Korrektur 329273 in dem CU36 nicht den gewünschten Erfolg gebracht.

Hat jemand von euch noch weitere Ideen?

Wir haben das Jahr 2022 und ich suche erst jetzt nach einer Lösung für das Problem. Wir haben seit Januar 2022 auch diesen sporadischen Fehler: „Die vorbereitete Anweisung mit dem Handle xxx wurde nicht gefunden.“ NAV2017, CU19, Gibt es schon eine Lösung dafür?

Moin ubefalo,

die offizielle Antwort von Microsoft lautet: Der Fehler wurde mit CU36 für NAV 2017 behoben.

In den CU-Beschreibungen zum CU 36 für NAV 2017 gibt es einen Eintrag:
ID: 329273
Title: "Could not find prepared statement with handle 12345 error message is displayed that requires you to restart the relevant NAV service."

Wir hatten daher ein technisches Update (nur Runtime, nicht die Datenbank-Objekte) auf das damals aktuellste CU (43) gemacht, was jedoch den Fehler nicht behoben hatte.
Möglicherweise wurde der Fehler tatsächlich mit CU36 behoben, hat sich dann aber in einem späteren CU wieder eingeschlichen. (Sowas in der Art gab es in der Vergangenheit leider schon häufiger.)
Eventuell wurde der Fehler mittlerweile in einem späteren CU (>43) erneut behoben.

Bei uns tritt der Fehler seltsamerweise seit geraumer Zeit nicht mehr auf, obwohl wir weiterhin auf CU43 sind.
Vielleicht haben unsere Systemintegratoren auch die NSTs in einem der regelmäßigen IT-Wartungsfenster vollständig deinstalliert und CU43 neu installiert.

Hallo zusammen,

seit diesem Monat tritt das Problem auch bei uns auf, wir sind auf NAV 2017 2.1

Es tritt an verschiedenen Stellen im System auf, manchmal beim Login, manchmal beim Öffnen von Pages und manchmal beim Drucken. In der Regel passiert es auf wenigen NSTs, nicht auf allen. Manchmal liegen Tage oder auch nur Stunden dazwischen. Meist sind dann alle Benutzer auf dem NST betroffen... Also genau wie Ihr alle beschrieben habt. Wir haben vom Code her nichts verändert, was dazu irgendwie passt.

Allerdings sind die NST gerade in eine neue virtuelle Umgebung umgezogen. Vielleicht hat es etwas damit zu tun. Wir schauen uns gerade an, ob wir da noch was finden können.

Auf CU 36 zu wechseln ist natürlich ein großer Sprung für uns, und sicher nichts, was wir dann mal ganz schnell machen. @Timo Lässer: Zu Mal wenn ich Deinen Kommentar richtig verstehe hat CU43 nicht direkt den Effekt gebracht, sondern es hat sich später irgendwann / irgendwie gelöst.

Vielleicht können die anderen die hier das Problem hatten, mal sagen, ob und wie sie es gelöst haben, damit wir ein paar Optionen haben. Ich verstehe leider halt auch gar nicht, wo das jetzt auf einmal herkommt...

Gruß
sas_fisch