DBGrid sortieren mit unterschiedlichen DBMS Treibern

[jobo]

Ich würde bei bei den Treibern alle OLEDB Settings / Defaults vergleichen.
Jede DB Session "lebt" in dem Glauben bestimmte Locale Settings nutzen zu müssen. Die Herkunft dieser Vorgaben kann ganz unterschiedlich sein und am Ende je Tabellenspalte und definierter Locale verschieden.
MS erfindet ja gerne das Rad neu, aber vielleicht nicht so grundlegend. Meine Idee wären -dank MSO 365 Cloud- geänderte Standard Locale Settings...
Und ich würde nicht drauf wetten, aber diese OLEDB Treiber sind doch com server und da geschieht vermutlich das gleiche, wie mit anderen com servern, die Interfaces werden bei Neuinstallation jeweils durch den aktuellsten bedient. Bedeutet, die alten sind noch da, man muss sie "nur" gezielt über die Version ansprechen. Evtl. hilft dabei ein gezielter, programmatischer Aufbau der Connection.

[Humbucker]

Hallo,

ich habe zwischenzeitlich neue Erkenntnisse zum Thema. Das Problem hängt mit der unterschiedlichen Interpretation des Treibers der SQL-Abfrage zusammen. Felder, die in der SQL-Abfrage mit 'as' erzeugt werden, werden unterschiedlich interpretiert. Im konkreten Kontext wird das Feld 'Sendungsnummer' in der SQL-Abfrage wie folgt erzeugt:

Code:

iif(ISNULL(A.SENDUNG),iif(A.Abrechnungstyp = 69 ,''Mehrere'', ''Keine''), S.SENDUNGSNUMMER) as Sendungsnummer

Hieraus erzeugt der Treiber Microsoft.ACE.OLEDB.12.0 (Access 2007 Database Engine) den Feldtyp ftWideString (siehe Image1).

Hieraus erzeugt der Treiber Microsoft.ACE.OLEDB.16.0 (Access 2016 Database Engine) den Feldtyp ftWideMemo (siehe Image2) - und Memofelder können nicht sortiert werden

Da die Erzeugung von Feldern in einer SQL-Abfrage mit 'as' eine gängige Praxis in unserer Anwendung ist, kommt aufgrund der schieren Menge eine Umstellung per Cast nicht in Frage.

Gibt es eine Eigenschaft mit der dieses Verhalten der Treiber gesteuert werden kann? Vielleicht mit der ADOConnection? Oder mit dem Connection String der ADOConnetion?

Gruß Michael

[Humbucker]

Zitat von jobo:

Ich würde bei bei den Treibern alle OLEDB Settings / Defaults vergleichen.
Jede DB Session "lebt" in dem Glauben bestimmte Locale Settings nutzen zu müssen. Die Herkunft dieser Vorgaben kann ganz unterschiedlich sein und am Ende je Tabellenspalte und definierter Locale verschieden.
MS erfindet ja gerne das Rad neu, aber vielleicht nicht so grundlegend. Meine Idee wären -dank MSO 365 Cloud- geänderte Standard Locale Settings...
Und ich würde nicht drauf wetten, aber diese OLEDB Treiber sind doch com server und da geschieht vermutlich das gleiche, wie mit anderen com servern, die Interfaces werden bei Neuinstallation jeweils durch den aktuellsten bedient. Bedeutet, die alten sind noch da, man muss sie "nur" gezielt über die Version ansprechen. Evtl. hilft dabei ein gezielter, programmatischer Aufbau der Connection.

Habe ich gemacht und keine Unterschiede gefunden. In unserer Anwendung können die Treiber beim Start gewählt werden. In diesem Dialog stehen dann auch die Eigenschaften der Treiber zur Verfügung (die dann in den ConnectionString einfließen und an TADOConnection weitergegeben werden), so dass diese recht einfach verglichen werden können. Das Verhalten ist sogar provozierbar, indem nur der Treibername im Debug geändert wird (aus 12.0 mach 16.0), so dass alle anderen Eigenschaften identisch bleiben sollten.

Bezüglich des gezielten Ansprechens des Treibers ist zu sagen, dass genau das der Login Dialog macht. Es wird gezielt ein Treiber angesprochen und konfiguriert, der dann übergeben wird. Das Problem ist das Updateverhalten von Office 365, dass den korrekt und konkret angesprochenen Treiber verändert.