Howdy!
Gib ein Request an
QC auf und fixe das Ding wie damals an zentraler Stelle.
--
Einer der Gründe für den Multi-Tier Approach bei
DB Anwendungen und das Briefcase Model waren die Kosten beim Erzeugen einer Datenbank Session. Verkauft wurde damals, was war noch vor Zeiten performanter Internetverbindungen und Enterprise Web in der Breite. Hernach blieb noch das Brief Case Model und der Export von Daten als
XML Datei, das war modern. Die Java Stacks kannten keine Middleware und sendeten Daten als
XML Stream übers Netz.
Es spielt noch rein, dass
Access einen Write Through über
ODBC auf zumindest Oracle (indirekt auch über Views) und
SQL Server auf Master Detail Beziehung konnte bewerkstelligen. Der Einfluss der
BDE, damals waren die Zahl der Datentypen noch sehr überschaubar und diese waren eher primitiv (nicht komplex), ist auch ein wenig noch zu spüren.
Der Client Dataset gehört mehr oder minder zu
Midas und war eine in C/C++ implementierte Library welche verteilt werden musste und in 32-bit exklusiv vorlag und Quellcode, so ich mich recht erinnere, war nicht verfügbar. Deswegen scheuten die Delphi Progammierer den Zugang. Ich hoffe ich irre mich diesbezüglich nicht. Später wurde die Library in Pascal neu geschrieben usw...
Der Client Dataset kann heute viel und dessen Einsatz wurde beliebter, da Gruppierung und Aggregate lokal einfach per Definition gebildet werden können. Seit einer Präsentation vom David I. (vermutlich als Moderator) und dem Buch vom Cary Jenson sehe ich den Client Dataset anders und bin fast schon ein Fan. Naja, sagen wir einmal so.
Sowohl AnyDAC/FireDAC als auch die Komponenten von CoreLab/Devart entstanden hernach und insbesondere FireDAC löst das Thema anderes bspw. über den Einsatz von Commands. Bei FireDAC ist der Comp Layer ein Überbau in der obersten Schicht.
Der Dmitri A. verweis mich stolz wie Oskar auf das Demo mit den Commands und der Fähigkeit No Code ähnlich gelagerte Problemstellungen auf der Dataset Ebene zu lösen und ich dachte mir, 'Liab. Ist für die Weiber. Wer braucht so etwas?'. Wesentlich ist, Third-Party Komponenten sind mit solcher einer in Intention 'in mind' designed und eher von Grund auf. Das Datenbankdesign in die Richtung zu verbiegen, das wird es bei dir vermutlich schon gar nicht spielen.
Der Fluch dieser TDataSet Abstraktion ist einfach, dass diese gemeinsame Schicht zwar technisch Datenbanken abstrahiert, aber
ADO & Co und die Multi-Tier
DB Architecture (MTS,
COM+) mehr mit der mangelnden Performance des MS-
SQL Server zu tun hatte. Der fetzt erst seit der Version 2005 und später, zuvor wurde soviel pessimistisch gesperrt, dass der Sau grauste, selbst noch unter 7.
Welche
DB Client library nimmst du? Historisch bieten sich DBX und teils
ADO im Zusammenhang mit dem ClientDataSet an? Aber ich vermute du wirst den Patch lassen müssen.
lg.
Hoppy
Ich bin dabei ein Projekt von Delphi 7 auf Delphi 11 zu migrieren und habe ein Problem, das ich damals durch einen eigenen Eingriff in die Delphi-Quellcodes gelöst habe, das aber überraschenderweise auch in Delphi 11 immer noch besteht.
Es geht um eine
VCL-Anwendung mit Firebird-Anbindung. Der Zugriff auf Firebird erfolgt über TClientDataSets, die über TDataSetProvider mit TSQLDataSets kommunizieren. An vielen Stellen werden Master-Detail-Verknüpfungen benötigt. Diese werden bereitgestellt, indem im TClientDataSet der Detailtabelle die Eigenschaften "MasterSource", "MasterFields" und "IndexFieldNames" gefüllt sind. Bei einfachen
SQL-Selects funktioniert das auch:
Beispiel Master:
Select * from Liefeant
Beispiel Detail:
Select * from LieferantKontakt
Die Tabelle Lieferant hat ein Feld "Nummer", die Tabelle Kontakt ein Feld "LNummer", das sich auf das Feld Nummer bezieht. Mein Programm verhält sich genauso wie gewünscht.
Meistens sind die Detailtabellen aber ein wenig komplexer aufgebaut und stellen auch Daten anderer Tabellen bereit. Und dies führt zwangsläufig zu Fehlermeldungen von Delphi, egal ob Version 7 oder 11.
Hier einfache Beispiele für nicht funktionierende Abfragen, bei denen zur Tabelle LieferantKontakt noch ein Bezeichner aus einer Tabelle KontakArt geholt wird:
Detail:
Select L.*, K.Bezeichnung from LieferantKontakt left join KontaktArt K on L.KANummer = K.Nummer
oder
Select L.*, (Select K.Bezeichnung from KontaktArt where Nummer = L.KANummer) as Bezeichnung from LieferantKontakt
Ich habe per Debugging im Delphi-Quellcode die Funktion "AddParamSQLForDetail" in der
Unit "Data.DBCommon.Pas" als Ursache für das Problem herausgefunden, die einfach fehlerhaft arbeitet und offensichtlich nur mit einfach gestrickten Anweisungen der Art "Select * from <Table> order by <Column>" zurechtkommt. Weder Joins noch Unterselects werden in irgendeiner Form korrekt erkannt und berücksichtigt. Das in meinem obigen Beispiel von der Funktion eingefügte "where LNummer = ?" landet in diesen Fällen an der falschen Stelle und führt somit zu einer ungültigen Select-Anweisung.
Natürlich könnte ich das Problem irgendwie umschiffen oder wieder - wie damals bei Delphi 7 - den delphieigenen Code korrigieren. Aber das erste macht mir aufgrund des Projektumfangs ziemlich viel Aufwand und das zweite zwingt mich bei jedem Delphi-Update die Korrekturen erneut vorzunehmen.
Kennt irgend jemand von euch (oder von Embarcadero) dieses Problem und hat evtl. eine bessere Lösung?