DBGrid sortieren mit unterschiedlichen DBMS Treibern

[Humbucker]

Hallo,

ich verwende folgenden Code zur Sortierung eines DBGrid:

Delphi-Quellcode:

procedure THHDGrid.Sort;
begin
  try
    if DataSource.DataSet.ClassName = 'TADOQuery' then
      if TADOQuery(DataSource.DataSet).Active then
        if DescParam then
          TADOQuery(DataSource.DataSet).Sort := '[' + TitleName + '] DESC'
        else
          TADOQuery(DataSource.DataSet).Sort := '[' + TitleName + ']'
      else
    else if DataSource.DataSet.ClassName = 'TRxMemoryData' then
      if TRxMemoryData(DataSource.DataSet).Active then
        if DescParam then
          TRxMemoryData(DataSource.DataSet).SortOnFields('[' + TitleName + ']', True, True)
        else
          TRxMemoryData(DataSource.DataSet).SortOnFields('[' + TitleName + ']', True, False);
  except
    on e: exception do
    begin
        MessageDlg(e.Message, mtInformation, [mbOK], 0);
    end;
  end;
end;

Bei der Verwendung unterschiedlicher Datenbanktreiber für Access verhält sich die Sortierung (in der gleichen Datenbank) unterschiedlich:

Provider=Microsoft.ACE.OLEDB.12.0 (Access 2007 Database Engine): Feld "Sendungsnummer" wird aufsteigend und absteigend korrekt sortiert
Provider=Microsoft.ACE.OLEDB.16.0 (Access 2016 Database Engine): Feld "Sendungsnummer" wird nicht sortiert.

Es wird eine Exception vom System erzeugt -> e.Message: 'Die Reihenfolge kann nicht angewendet werden'

Auch an anderen Stellen habe ich festgestellt, dass sich die Treiber der Datenbank unterschiedlich verhalten.

Unter normalen Umständen müsste ich mich mit dem Thema überhaupt nicht beschäftigen, da wir die Microsoft Access Database Engine 2007 bei der Installation unserer Anwendung mitinstallieren und den Microsoft.ACE.OLEDB.12.0 Treiber verwenden. Leider habe ich nun in den vergangenen Wochen feststellen müssen, dass eine Microsoft Office 356 oder eine Microsoft Office 2016 Installation die Microsoft Access Database Engine 2007 verändert und auf die Funktionalitäten von Access 2016 umstellt. Damit verhält sich dann der Microsoft.ACE.OLEDB.12.0 Treiber wie ein Microsoft.ACE.OLEDB.16.0 Treiber. Auch eine "Side by Side" Installation der Microsoft Access Database Engine 2007 mit dem Parameter /Passive hat keine Verbesserung gebracht.

Hat jedmand eine Idee, was das Problem beim Sortieren des DBGrid mit dem Microsoft.ACE.OLEDB.16.0 Treiber verursacht und wie man damit umgehen kann?

Gruß Michael

[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.