[GELÖST] MSSQL-ODBC: HY010-Fehler

[Ich934]

Hallo,

ich greife in einem Programm mittels ODBC auf einen MS SQL-Server zu. Das hat bisher auch gut funktioniert. Seit der Umstellung auf Lazarus 2.0.10 und FPC 3.2 erhalte ich hier einen HY010-Fehler. Das heißt, dass im Hintergrund noch Aktionen laufen. Allerdings erhalte ich diesen Fehler auch, wenn nur ein Connect und ein Disconnect vom Programm ausgeführt wird.

Hat hier jemand eine Idee?

Aufbau der Verbindung:

Code: Alles auswählen

procedure TMSSql.openConnection;
begin
  // wenn nicht verbunden
  if (FMSSQLConnection = nil) or (not FMSSQLConnection.Connected) then
  begin
    try
      FMSSQLConnection := TODBCConnection.Create(nil);
      FSQLTransaction := TSQLTransaction.Create(nil);
      FMSSQLConnection.Params.Add('Dsn=' + getMSSQLServer);
      FMSSQLConnection.Params.Add('Server=' + getMSSQLServer);
      FMSSQLConnection.Params.Add('AUTOCOMMIT=1');
      FMSSQLConnection.Transaction := FSQLTransaction;
    except
      on E: Exception do
        WriteLn('Fehler bei der Verbindung zur MSSQL Datenbank!');
    end;
  end;
end;   

Trennen der Verbindung:

Code: Alles auswählen

procedure TMSSql.closeConnection;
begin
  // prüfen ob verbunden
  if FMSSQLConnection.Connected then
  begin
    try
      // Transaktion beenden
      FSQLTransaction.CommitRetaining;
      FSQLTransaction.EndTransaction;
      // Verbindung schließen
      FMSSQLConnection.Close(True);
    except
      on E: Exception do
        Write('Fehler beim Close!');
    end;
  end;
end;   

Ausgabe des Programms:

Code: Alles auswählen

[FORMS.PP] ExceptionOccurred
  Sender=EODBCException
  Exception=Could not free ODBC Environment handle. ODBC error details: LastReturnCode: SQL_ERROR; Record 1: SqlState: HY010; NativeError: 0; Message: [Microsoft][ODBC Driver Manager] Fehler in der Funktionsreihenfolge;
  Stack trace:
  $00000001001F44D9
  $00000001001F466F
  $00000001001F87A4
  $000000010000F06B
  $00000001001F8977
  $00000001000118F7
  $0000000100011BC2
  $0000000100011C6A
  $0000000100003845  main,  line 165 of RiedlEDIConv.lpr
  $0000000100003866  main,  line 165 of RiedlEDIConv.lpr
  $0000000100017B30
  $0000000100002D30
  $00007FFF81CA7034
  $00007FFF837BCEC1
Exception at 00000001001F44D9: EODBCException:
Could not free ODBC Environment handle. ODBC error details: LastReturnCode: SQL_ERROR; Record 1: SqlState: HY010; NativeError: 0; Message: [Microsoft][ODBC Driver Manager] Fehler in der Funktionsreihenfolge;.
Marked memory at $00000000086FF008 invalid
Wrong size : 18369900232523579118 allocated 18369900232523532423 freed

Die Zeile 165 in der .lpr-Datei ist übrigens das "end.". Ich bin hier irgendwie etwas ratlos...

[fliegermichl]

Was mir auffällt ist, wenn MSSQLConnection nicht nil aber auch nicht connected ist, erzeugst du sie dennoch neu.
Genauso wird sie bei closeConnection nicht freigegeben. Evtl. hängt das damit zusammen.

[Ich934]

Ich habe jetzt ein "Free" eingefügt, welches aber nicht zum Erfolg geführt hat.

In in meinem Fall verbindet er sauber einmal am Anfang des Programms, läuft durch (macht nichts am MS SQL) und schließt dann die Verbindung. So gesehen sollte das alles gehen. Mir ist schleierhaft, was hier im Hintergrund auch hängen sollte. Es wird keinerlei Abfrage ausgeführt. Selbst wenn sollte der "Commit" und die "EndTransaction" das alles bereinigen.

[af0815]

Siehe auch https://techcommunity.microsoft.com/t5/ ... -p/1314255

CU8 = Kumulatives Update 8 für SQL Server
Hast du genau die CU6 Version ? Frag mich nur nicht wie man das abfragt

Der HY010 dürfte aber ein weit verbreitetes Problem auch bei PHP und MS Selbst gewesen sein.

[Ich934]

Nein, ist ein 2016er Server. Aber das mit einem Update könnte durchaus sein. Das würde erklären, warum das auf einmal kam ... Aber das kann ich erst nächste Woche prüfen.

Aber danke für den Hinweis.

[af0815]

Es geht hier nicht um den Server, das spielt da nicht die Rolle, sondern um die Treiberschicht.

Es ist bei mir nicht aufgefallen, da ich ODBC nicht verwende sondern immer SQL-DB (oder tw. auch ZEOS) die über die FreeTDS direkt zugreifen. ODBC ist auch nicht wirklich gut kompatibel mit Linux gewesen, während die SQL-DB bzw. ZEOS immer schon sehr gut in Linux funktioniert hat. Und damit Programme relativ einfach für Windows und Linux zu schreiben waren.

Schon unter Delphi habe ich entweder mit RDO oder ADO auf die DB zuzugreifen, nachdem es mit ODBC immer etwas problematisch war, da oft nicht alles von den DB unterstützt wurde.

[Ich934]

So, ich hab das Ganze jetzt von ODBC auf MSSQL-Funktionen mit FreeTDS umgestellt. Das Ergebnis ist aber das Gleiche ...

[af0815]

Kannst du das auf ein Beispiel reduzieren, weil MSSQL habe ich als Testserverinstallation, somit könnte ich das direkt testen.

[Ich934]

Oh, man. Fehler gefunden ...

Also, es war nicht der MSSQL-ODBC bzw. nicht nur. Diesen habe ich ja umgestellt auf die MSSQL-Funktionen und trotzdem blieb der Fehler. Das Programm hat jedoch noch eine weitere ODBC-Verbindung eingebaut, und zwar zu einer iSeries.

Beheben konnte ich jetzt das Problem indem ich die zwei Datenbankklassen explizit mit einem Free freigebe. Eigentlich bin ich davon ausgegangen, dass der Destroyer automatisch beim Beenden des Programmes für alle noch offenen Klassen aufgerufen wird und somit das, wenn man einmal was übersieht, das bereinigt wird. Scheinbar ist Freepascal hier etwas eigen. Ein sauberes Free eingefügt und Fehler verschwunden.

[af0815]

Beheben konnte ich jetzt das Problem indem ich die zwei Datenbankklassen explizit mit einem Free freigebe. Eigentlich bin ich davon ausgegangen, dass der Destroyer automatisch beim Beenden des Programmes für alle noch offenen Klassen aufgerufen wird und somit das, wenn man einmal was übersieht, das bereinigt wird. Scheinbar ist Freepascal hier etwas eigen. Ein sauberes Free eingefügt und Fehler verschwunden.

Der Destroyer mach das, du ihm gesagt hast, nicht das was gemeint wurde. Es gibt hier im Normalfall keinen Garbage-Collector. Entweder das Objekt gehört wen, dann ist der normalerweise dafür zuständig

[Ich934]

Ich habe bei der Klasse einen Destroyer angelegt. In diesem wurde die Prozedur zum Schließen Beenden der Transaktion und schließen der Verbindung aufgerufen.

Ich war jetzt eigentlich der Meinung, dass beim Beenden eines Programmes diese Klassen bereinigt werden und die Destroyer aufgerufen werden. Auch wenn man mal schlampig programmiert, so wie hier. Mit einem Verhalten wie in meinem Fall mit einem solchen Fehler habe nicht gerechnet.

OK, jetzt wird das sauber mit einem Free bereinigt und es geht.

[PascalDragon]

Ich war jetzt eigentlich der Meinung, dass beim Beenden eines Programmes diese Klassen bereinigt werden und die Destroyer aufgerufen werden. Auch wenn man mal schlampig programmiert, so wie hier. Mit einem Verhalten wie in meinem Fall mit einem solchen Fehler habe nicht gerechnet.

Nein, die RTL hat keine Ahnung welche Klasseninstanzen alles angelegt werden und du als Entwickler bist selbst dafür verantwortlich alle Instanzen korrekt freizugeben. Einzige Ausnahme sind TComponent-Abkömmlinge, wenn deren AOwner-Parameter im Konstruktor angegeben wurde (und Klassen, die rein über Interfaces angesprochen werden und damit der Referenzzählung unterliegen).

Du könntest dein Programm mal mit -gh (in Lazarus unter Projekteinstellungen -> Compilereinstellungen -> Debuggen -> Heaptrc-Unit verwenden (-gh)) kompilieren und schauen was du sonst noch für Speicherlecks hast (da ein fehlendes Free letztlich zu einem Speicherleck führt).

[Ich934]

Das hab ich jetzt gemerkt. Gut, also einfach darauf achten, sauber zu programmieren.

Man ist einfach durch die Garbage Collectoren von diversen anderen Sprachen verwöhnt. Aber an sich ist das ja nicht schlecht so. Danke für den Tipp.

[m.fuchs]

(und Klassen, die rein über Interfaces angesprochen werden und damit der Referenzzählung unterliegen).

COM-Interfaces meinst du, CORBA sollte ja nicht referenzgezählt werden. Oder hat sich da inzwischen etwas geändert?

[PascalDragon]

(und Klassen, die rein über Interfaces angesprochen werden und damit der Referenzzählung unterliegen).

COM-Interfaces meinst du, CORBA sollte ja nicht referenzgezählt werden. Oder hat sich da inzwischen etwas geändert?

Ja, ich meine COM-Interfaces. Den meisten Leuten sagen die CORBA (oder Raw) Interfaces wahrscheinlich nichts, deswegen habe ich sie nicht extra herausgestellt...