Wie geht es weiter mit Delphi? Ernüchternde Support-Aussagen

[Papaschlumpf73]

Bei mir im Schrank steht noch die Box mit Delphi 1. Schon damals war mir klar, dass Delphi für die Entwicklung von Datenbankanwendungen (wie) geschaffen war. Knapp 30 Jahre später, sieht das schon anders aus.

Meine Datenbankanwendungen arbeiten alle mit ADO-Verbindungen und greifen weitestgehend auf Microsoft SQL Server im lokalen Netzwerk zu. FireDAC habe ich nie benutzt, da ich i.V.m. mit VCL-Anwendungen keine Vorteile sehe und auch nicht bereit bin, für die Entwicklung reiner Client-Anwendungen eine Delphi Enterprise Lizenz zu bezahlen (das soll hier auch nicht das Thema sein).

Unter Verwendung neuerer OLE-DB-Provider z.B. „Microsoft-OLE DB-Treiber 19 für SQL Server“ i.V.m. SQL-Servern ab Version 2016 können viele Datensatzänderungen nicht mehr mit IrgendeinDataSet.Post gespeichert werden. Es wird öfters, jedoch nicht immer folgender Fehler ausgegeben:

„Die zum Aktualisieren angegebene Zeile wurde nicht gefunden. Einige Werte wurden seit dem letzten Lesen ggf. geändert.“

Das passiert vermehrt, wenn ein DateTime-Feld in der Datenbank Millisekunden enthält, die Delphi möglicherweise ignoriert. Beim Speichern des Datensatzes wird dann wahrscheinlich ein abweichender Wert gefunden und führt zu diesem Fehler. Möglicherweise haben ja die alten OLE-DB-Provider auch keine Millisekunden geliefert, so dass dieses Problem früher nicht bestand.

Jetzt könnte ich natürlich einfach weiter die alten OLE-DB-Provider benutzen; aber:
- Microsoft entwickelt diese seit zig Jahren nicht mehr weiter; möglicherweise funktionieren diese nicht mehr mit der nächsten SQL-Server-Generation

- Die neuen OLE-DB-Provider haben auch Vorteile. Z.B. werden damit in Delphi auch reine Datumsfelder TDateField unterstützt, die bei den alten Providern immer als TStringField ausgegeben wurden.

Um eine Lösung für das Problem herbeizuführen, habe ich meinen einzigen Gratis-Support-Fall für dieses Jahr eingesetzt und folgende Antwort (verkürzt und übersetzt) erhalten:

Wir haben dieses Problem auch mit FireDAC gehabt, mit Datenbanken mit einem Kompatibilitätslevel >= 130. Der FireDAC-Entwickler sagt, dass er nichts tun kann.
Lösungsvorschlag: http://www.delphigroups.info/2/63/218724.html

Das bedeutet jedoch, dass zwischenzeitliche Datensatzänderungen anderer Anwender einfach überschrieben werden.

Meine Firma habe ich jetzt seit über 20 Jahren. In dieser Zeit musste ich noch nie einem Kunden sagen, das man da nichts machen kann. Klar, manchmal ist es aufwändig, manchmal teuer, manchmal fehlt auch gerade die Zeit. Aber, dass man gar nichts machen kann….

Wie soll es mit Delphi weiter gehen, wenn Probleme auf diese Art gelöst bzw. einfach nur umgangen werden?

Für alle, die sich das Problem mal anssehen wollen, anbei eine schnell zusammen geklöppelte Beispielanwendung.

[jaenicke]

Ich frage mich, welche Lösung du dir vorstellst. Wie sollte denn das rein logisch in den Delphi-Komponenten gelöst werden? Mir fällt auch keine sinnvolle Lösung ein, wenn der Server dazu nichts anbietet (wie automatisches Mergen, falls möglich und gewünscht)...

[Sinspin]

Das sieht mir eher nach einem konzeptionellen Problem aus.
Wenn ich dich richtig verstanden habe verwendest du TimeStamp Werte zur identifikation von Datensätzen.
Wäre da nicht ein AutoInc Integer besser geeignet?
TDateTime/TimeStamp ist in Delphi ein Gleitkommawert, da sind Ungenauigkeiten per Design.
MS SQL Server verwendet intern vermutlich Int64 um sich solcher Probleme zu entziehen.
Mit FireDAC kannst du Type Mappings durchführen, ich sehe da also eher eine Chance weiter zu kommen.

Das hat jetzt aber rein garnix mit der Zukunft von Delphi zu tuen.
Klar ist es nicht unbedingt clever Komponentenpakete an Delphi Versionen zu binden.
Aber das ist nunmal aktuell so. Vlt ändert sich das irgendwann mal und es gibt ein Delphi und Pakete mit zusätzlichen Komponenten.

[Papaschlumpf73]

Zitat von jaenicke:

Ich frage mich, welche Lösung du dir vorstellst. Wie sollte denn das rein logisch in den Delphi-Komponenten gelöst werden? Mir fällt auch keine sinnvolle Lösung ein, wenn der Server dazu nichts anbietet (wie automatisches Mergen, falls möglich und gewünscht)...

Ich stelle mir folgende Lösung vor: Der Emba-Support ermittelt die Ursache des Problems und versucht es dann zu lösen. Es kann m.E. ja nur 2 Ursachen geben:

a) der neue OLE-DB-Provider arbeitet fehlerhaft und liefert falsche Daten aus, die hinterher beim Zurückschreiben in die Datenbank nicht mehr übereinstimmen, obwohl sie gar nicht verändert wurden. Hier sollte der Emba-Support ein Ticket bei Microsoft eröffnen.

b) Die Delphi-Komponenten erhalten von den neuen Providern Millisekunden, die in Delphi jedoch nicht gespeichert oder falsch gerundet werden. Beim Zurückschreiben der Daten in die Datenbank stimmen diese dann natürlich nicht mehr mit den ursprünglichen Daten überein und führen zu dem Fehler. In diesem Falle sollte Emba die Komponente so erweitern, dass sie die vom OLE-DB-Provider gelieferten Daten auch vollständig speichern und für den Datenabgleich vollständig an den SQL-Server zurück senden.

[haentschman]

Zitat:

der neue OLE-DB-Provider arbeitet fehlerhaft

...ich habe mit den OLE Treibern auch Probleme...wenn ich vergessen hatte den NativeTreiber2012 zu installieren

Damit geht es ohne Probleme. Versuch das mal.

Zitat:

https://www.microsoft.com/de-de/down....aspx?id=50402

[Papaschlumpf73]

Zitat von Sinspin:

Das sieht mir eher nach einem konzeptionellen Problem aus.
Wenn ich dich richtig verstanden habe verwendest du TimeStamp Werte zur identifikation von Datensätzen.
Wäre da nicht ein AutoInc Integer besser geeignet?
TDateTime/TimeStamp ist in Delphi ein Gleitkommawert, da sind Ungenauigkeiten per Design.

Leider völlig falsche Annahmen - siehe Beispielanwendung:
CREATE TABLE [dbo].[ADOTest]([ID] [int] IDENTITY(1,1) NOT NULL, [DateTimeField] [datetime] NOT NULL, CONSTRAINT [PK_ADOTest] PRIMARY KEY CLUSTERED([ID] ASC))

[Bernhard Geyer]

Schau dir mal UniDac an: https://www.devart.com/unidac/
Kostet zwar ein paar €, aber haben seit Jahren damit die Supportprobleme mit dem DB-Zugriff für MySQL und Oracle auf "Nahe 0" reduziert.
Bei MS SQL Server hatten wir schon eine direkt auf ADO/OLE DB aufsetzende Schnittstelle, so das die Umstellung auf Unidac (aktuell) keinen mehrwert bieten würde.

[Papaschlumpf73]

Zitat von haentschman:

Zitat:

der neue OLE-DB-Provider arbeitet fehlerhaft

...ich habe mit den OLE Treibern auch Probleme...wenn ich vergessen hatte den NativeTreiber2012 zu installieren

Damit geht es ohne Probleme. Versuch das mal.

Zitat:

https://www.microsoft.com/de-de/down....aspx?id=50402

Danke, ich weiß. Mit den alten OLE-DB-Providern gehts ja auch noch. Nur der SQL Native-Client wird auch nicht weiter entwickelt:

"Die SQL Server Native Client (SQLNCLI) bleibt veraltet und wird nicht empfohlen, sie für neue Entwicklungsarbeit zu verwenden. Verwenden Sie stattdessen den neuen Microsoft OLE DB-Treiber für SQL Server (MSOLEDBSQL), der mit den aktuellsten Serverfeatures aktualisiert wird."

https://docs.microsoft.com/de-de/sql...l-server-ver16

[Papaschlumpf73]

Zitat von Bernhard Geyer:

Schau dir mal UniDac an: https://www.devart.com/unidac/
Kostet zwar ein paar €, aber haben seit Jahren damit die Supportprobleme mit dem DB-Zugriff für MySQL und Oracle auf "Nahe 0" reduziert.
Bei MS SQL Server hatten wir schon eine direkt auf ADO/OLE DB aufsetzende Schnittstelle, so das die Umstellung auf Unidac (aktuell) keinen mehrwert bieten würde.

Danke für den Tipp. Der Verzicht auf FireDAC war eher eine Prinzipienfrage. Geld ist ja da...
Eigentlich suche ich auch keine Ausweichlösung, sondern wollte mich mit euch über den generellen Umgang bei Emba mit solchen Problemen unterhalten. Daher auch meine etwas provokante Überschrift. Nur mal so aus meiner Firma: Wenn ich die Probleme/Fehler meiner Software nicht behebe - oder diese nachvollziehbar einem anderen zuschreiben kann - würden sich meine Kunden früher oder später verabschieden.

[Redeemer]

Zitat von Papaschlumpf73:

Zitat von haentschman:

Zitat:

der neue OLE-DB-Provider arbeitet fehlerhaft

...ich habe mit den OLE Treibern auch Probleme...wenn ich vergessen hatte den NativeTreiber2012 zu installieren

Damit geht es ohne Probleme. Versuch das mal.

Zitat:

https://www.microsoft.com/de-de/down....aspx?id=50402

Danke, ich weiß. Mit den alten OLE-DB-Providern gehts ja auch noch. Nur der SQL Native-Client wird auch nicht weiter entwickelt:

"Die SQL Server Native Client (SQLNCLI) bleibt veraltet und wird nicht empfohlen, sie für neue Entwicklungsarbeit zu verwenden. Verwenden Sie stattdessen den neuen Microsoft OLE DB-Treiber für SQL Server (MSOLEDBSQL), der mit den aktuellsten Serverfeatures aktualisiert wird."

Da bei Windows 10 nur der SQLNCLI für SQL Server bis <=2005 mitgeliefert wird, brauchst du den SQLNCLI 2014 aber oft weiterhin. Selbst für SDAC von Devart braucht man den. Betrifft vor allem den Zugriff auf bestimmte benannte Instanzen und ab 2008 eingeführte Datentypen. Für die Datentypen kann man sich Unterstützerklassen schreiben, muss dann aber deren "As"-Eigenschaften verwenden.