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…. :cry:

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:

Zitat von jaenicke (Beitrag 1508452)

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:

Zitat von Sinspin (Beitrag 1508455)

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:

Zitat von haentschman (Beitrag 1508458)

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:

Zitat von Bernhard Geyer (Beitrag 1508460)

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:

Zitat von Papaschlumpf73 (Beitrag 1508461)

Zitat:

Zitat von haentschman (Beitrag 1508458)

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.

[Papaschlumpf73]

Zitat:

Zitat von Redeemer (Beitrag 1508464)

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.

Wo kriegt man den denn her? Ich dachte bei SQLNCLI 2012 ist Schluss...

[himitsu]

Zitat:

Schon damals war mir klar, dass Delphi für die Entwicklung von Datenbankanwendungen (wie) geschaffen war

ja klar ... Delphi (Turbo Pascal) wurde ja von einer Firma (Borland) übernommen, welche u.A. mit Datenbanken (Oracle) ihr Geld verdiente.


[add]

Zitat:

SDAC ist natürlich nur für MSSQL. Aber es gibt ja auch UniDac..

PgDAC uvm. :stupid:

[BigAl]

Ich verwende seit etwa 15 Jahren (+/-) das SDAC von Devart für den Zugriff auf SQL-Server Datenbanken. Alle meine Anwendungen laufen bei Kunden weltweit im 7/24 Betrieb. Das ist super robust und wird auch immer noch sehr gut gepflegt (und bei Problemen erhält man schnellen Support). SDAC ist natürlich nur für MSSQL. Aber es gibt ja auch UniDac... Soviel zur Zukunftssicherheit.

Ich denke aber auch - wie meine Vorredner - dass das eher ein Designproblem ist...

[Uwe Raabe]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508462)

Eigentlich suche ich auch keine Ausweichlösung, sondern wollte mich mit euch über den generellen Umgang bei Emba mit solchen Problemen unterhalten.

Die Aussage der FireDAC-Entwickler sagt, dass er nichts tun kann muss ja nicht auf ewig so bleiben. Es ist gar nicht so unwahrscheinlich, dass das in einem zukünftigen Release gelöst wird. Manchmal sind dazu vielleicht größere Umbauten nötig, die in einem schnellen Fix nicht unterzubringen sind - wer weiß das schon.

[Papaschlumpf73]

Jedenfalls finde ich es sehr schade, dass viele Funktionalitäten, die man früher bedenkenlos einsetzen konnte, nicht mehr dem Stand der Technik entsprechen. Oft geht’s nur noch mit Gefrickel oder Komponenten von Drittanbietern.

Nur ein paar Beispiele:

• Die alten OLE DB Provider funktionieren; die neuen nur mit Einschränkungen
• FTP funktioniert - haut dir aber jeder Admin zurecht um die Ohren; SFTP/FTPS gibt’s nicht
• WSDL-Dateien einlesen geht - sofern diese den technischen Stand von vor 15 Jahren haben. Bei Standards wie WSSecurity muss schon gefrickelt werden. Und Dateianhänge mit MTOM+XOP…

Dabei sind doch Datenbankanbindung, Datenaustausch und Webservices pure Basics, die jede Entwicklungsumgebung unterstützen sollte. Also nach heutigen Standards und nicht denen von vor 10-15 Jahren.

Vielleicht werde ich ja auch nur alt und sentimental…

[Sinspin]

Was meinst Du mit SFTP/FTPS geht nicht? Du meinst es gibt keine Komponente dafür?
Da sind wir wieder bei der Frage, was sollte bei Delphi dabei sein und was muss man zukaufen.

Keine Frage, das Internet und seine Protokolle sind Heute sowas wie das Öl im Getriebe.
Aber auch Öl kauft man zu.
Emba könnte ein Paket von Pro-Komponenten anbieten. Aber warum? Die haben sicher schon genug zu tuen die anderen Platformen aktuell zu halten.

Es gibt eine ganze Reihe Hersteller die sich seit Jahren ins Zeug legen und alle wesentlichen Protokolle implementieren. Das kostet Zeit und Geld.
Zum Beispiel /N-Software, die kenne ich seit 15 Jahren. Geht es um Kommunikation sind die mein Öl Lieferant ;-)
Umsonst sind die nicht. Aber dafür ist alles gleich aufgebaut, einfach zu verstehen und läuft stabil!

[himitsu]

Es gibt die INDY ... inzwischen sind die auch Multiplatform.

Und es gab das eigene Zeugs, wie TWebBrowser oder TNetHTTPClient, was auch Multiplatform ist.
Nur dass bei den "eigenen" Sachen schon ein bissl sehr viel fehlt.

[Papaschlumpf73]

Zitat:

Zitat von Sinspin (Beitrag 1508484)

Was meinst Du mit SFTP/FTPS geht nicht? Du meinst es gibt keine Komponente dafür?

Ja genau - also jedenfalls nicht im Delphi-Paket. Das ist halt meine Sentimentalität: Vor 25 Jahren konnte ich einfach so FTP einsetzen und das war ok. Und heute muss ich für dieselbe Funktionalität (nur eben sicherer) Komponenten woanders dazu kaufen. Es geht dabei nicht ums Geld, sondern vielmehr um den zeitlichen Aufwand - und jeder Hersteller hat so seine Eigenheiten, an die man sich gewöhnen muss. Was ist nun aus RAD geworden? Das R stand einst für Rapid - heute wohl eher für Rudimentär.

[Redeemer]

FTPS sollte mit Indy gehen, ist aber abhängig von OpenSSL.
SFTP, besser bekannt als SSH, geht ebenfalls nativ nicht kostenfrei. SSH ist aber halt auch nicht so einfach zu implementieren. Man sollte es kostenfrei mit der Putty-Suite hinbiegen können, damit hab ich bisher selbst aber nur eine SSH-Implementierung ohne SFTP gebaut.

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508465)

Zitat:

Zitat von Redeemer (Beitrag 1508464)

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.

Wo kriegt man den denn her? Ich dachte bei SQLNCLI 2012 ist Schluss...

Hab da was durcheinander gebracht. SQLNCLI 14 heißt das Ding und ist für SQL Server 2012. Fies ist auch, dass es Regressionen gibt. Beispiel: Wir hatten bei uns in der Firma vier unterschiedliche Versionen 14.0, ich nenne sie aufsteigend nach Build A < B < C < D. A konnte etwas nicht, B und D konnten es, aber C nicht.

[Bernhard Geyer]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508478)

Die alten OLE DB Provider funktionieren; die neuen nur mit Einschränkungen

Ist nicht mittlerweile (nach MS) ODBC state of the Art.
Bin ich froh das ich die ganzen ODBCE/DAO/RDO/ADO/ADO.NET/...-Techniken nicht alle mitmachen musste

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508478)

FTP funktioniert - haut dir aber jeder Admin zurecht um die Ohren; SFTP/FTPS gibt’s nicht

Bei uns wird oft HTTP-Upload genutzt. SFTP kommt selten vor.

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508478)

WSDL-Dateien einlesen geht - sofern diese den technischen Stand von vor 15 Jahren haben. Bei Standards wie WSSecurity muss schon gefrickelt werden. Und Dateianhänge mit MTOM+XOP…

Ja. Die SOAP-WS ist nicht gerade das Steckenpferd. Glücklicherweise vermeiden das auch die Kunden und setzen entweder SOAP + Security über Firewalls um (Anwendung außen vor) oder setzen gleich auf REST/JSON und Co. und vermeiden SOAP mittlerweile.
Aber vor kurzen mit einer Delphi+SOAP-Client geschafft das nach eine Navision-Update nicht die ganzen WSDLs komplett anders aussahen sondern wieder den alten Stand repräsentierten.

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1508478)

Dabei sind doch Datenbankanbindung, Datenaustausch und Webservices pure Basics, die jede Entwicklungsumgebung unterstützen sollte. Also nach heutigen Standards und nicht denen von vor 10-15 Jahren.

Ich finde das was mit REST/JSON eingebaut wurde ganz gut.
Und in der großen Version gibts ja auch Anbindungen für die ganzen ECommerce+CRM-Lösungen "out of the box" (wobei ich die Qualität dieser nicht bewerten kann).
Und mit Devart gibts für die DB-Schnittstelle ein sehr gute Alternative. Im Beruflichen Umfeld meisten kein relevanter Kostenfaktor (wenn man gesparte Supportzeit dagegen hält).

[himitsu]

Zitat:

Bei uns wird oft HTTP-Upload genutzt.

(Einwas)Upload ist auch bissl was Anderes,
als (Alles)Sehen, Runterladen und vielleicht noch Bearbeiten/Überschreiben/Löschen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1508502)

(Einwas)Upload ist auch bissl was Anderes,
als (Alles)Sehen, Runterladen und vielleicht noch Bearbeiten/Überschreiben/Löschen.

Das ist das was bei uns nötig ist.
Ein sftp war nur sehr selten nötig.
Und da war es jetzt meisten nicht mehr unser Anwendungsdom'ne sondern waren andere Zuständig.

[Sherlock]

Ich mache Delphi auch schon lange mit, zugegeben nicht ab Version 1 aber immerhin Version 5. Der Ansatz war dabei immer, daß ein Grundgerüst an Komponenten mitgeliefert wird, es aber eine große (zugegebenermaßen mittlerweile schrumpfende) Gemeinde an Drittanbietern gibt, auf die man zurückgreifen kann, wenn die Bordmittel nicht mehr ausreichen. Das ist sogar ein großes Marketingthema gewesen in der Blütezeit von Delphi. Das Emba also keine Komponenten für alles anbietet ist denen in keinster Weise vorzuwerfen. Zu SQL-Server Problemen kann ich nichts sagen, außer das so einiges was einem von Microsoft an Steinen in den Weg gelegt wird, auf wundersame Weise aufhört ein Problem zu sein, sobald man Visual Studio verwendet. Was für mich so ziemlich alle MS Produkte mit einem sehr faden Beigeschmack und einem großen Bogen versehen hat. Ich unterstütze quasi nur noch Windows als MS Produkt, aber mein Kundenkreis aus anderen OSen (macOS, iOS und Android) wird immer größer. Vielleicht verschwindet Windows bald ganz aus meinem Portfolio...

Sherlock

[Sinspin]

Ich würde es mittlerweile sogar begrüßen wenn man sich mit RAD Studio (Delphi/C++) mehr darauf konzentrieren würden die IDE und den Compiler Multiplattform tauglich zu bekommen und zu halten.
Das Emba auch Komponenten herstellt ist gut. Aber die sollten weitestgehend separat sein.
Basiscs mit enhalten, wie bisher, und alles anderen in separaten Paketen. Für jeden einzeln oder als Subscription zu erwerben.
Dieser Unsinn mit den verschiedenen RAD / Delphi / C++ Versionen mit integrierten pro Komponenten ist outdated (MO).

[norwegen60]

Auch wenn der Thread schon etwas älter ist, aber vielleicht hilfts dem ein oder anderen:
Ich hatte bei einigen Dialogen genau dieselbe Fehlermeldung "Die zum Aktualisieren angegebene Zeile wurde nicht gefunden.Einige Werte wurden seit dem letzten Lesen ggf. geändert"
Die Meldung war weg nachdem ich in der entsprechenden TAdoTable oder TAdoQuery

Delphi-Quellcode:

CursorLocation := clUseServer

gesetzt habe.
Ich hatte den Fehler aber bei Delphi XE
Der MsSQL-Profiler zeigte zwichen Post und folgendem Edit 2x

Code:

SET NO_BROWSETABLE ON

Die Tabelle hatte ein eindeutiges AutoInc Feld.
Man sollte aber beachten, dass clUseServer auch Einschränkungen mit sich bringt.

[generic]

@Papaschlumpf73 das Problem gab es auch schon 2016 und viele haben das für einen Aprilscherz von mir gehalten:
https://www.delphipraxis.net/188741-...zugreifen.html

[Papaschlumpf73]

Zitat:

Zitat von generic (Beitrag 1517554)

@Papaschlumpf73 das Problem gab es auch schon 2016 und viele haben das für einen Aprilscherz von mir gehalten:
https://www.delphipraxis.net/188741-...zugreifen.html

Umso trauriger, dass das Problem bis heute nicht gelöst worden ist und wohl auch nicht mehr gelöst werden wird…

[Sherlock]

Gibt ja zum Glück noch andere, bessere und günstigere RDBMS.

Sherlock

[Stevie]

Zitat:

Zitat von Sherlock (Beitrag 1517563)

bessere und günstigere RDBMS.

Wenn man beide Adjektive mit einer gewissen Gewichtung kombiniert vielleicht - nur besser möchte ich bezweifeln, allerdings hängt das stark von den Usecases ab.

Zum Thema über ADO auf SQL Server: wir nutzen genau diese Kombination schon seit Jahren ohne größere Probleme. Es gab mal ein paar Tücken mit durch ADO nicht direkt unterstützte Datentypen was eher an der Implementierung in Delphi und weniger an ADO selbst lag. Derzeit evaluieren wir die Umstellung auf den OLE DB Driver - es gab wohl Probleme mit der Version 19.0 - mit 18.6.3 funktionierte alles, kenne aber keine Details.
Da unsere Anwendung zwingend SQL Server vorraussetzt liebäugel ich schon seit langem mit SDAC, da die Komponente speziell auf SQL Server ausgelegt ist und man weniger mit dem kleinsten gemeinsamen Nenner arbeiten muss, wie es bei ADO ist.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1517571)

Da unsere Anwendung zwingend SQL Server vorraussetzt liebäugel ich schon seit langem mit SDAC, da die Komponente speziell auf SQL Server ausgelegt ist und man weniger mit dem kleinsten gemeinsamen Nenner arbeiten muss, wie es bei ADO ist.

Wir nutzen Unidac um auf MySQL/MariDB/postgresql und Oracle zuzugreifen.
Für MS SQL-Server haben wir noch einen eigenen Wrapper auf ADO/OLE DB.
Und auch noch mit SQL Server 2022 klappt der Zugriff (ohne Anpassung)

[Bbommel]

Dann noch die Ergänzung von mir dazu: wir nutzen auch UniDAC und in unserem Fall auch für den Zugriff auf MS SQL. Bisher hatten wir damit nie Probleme.