AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields
Thema durchsuchen
Ansicht
Themen-Optionen

DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields

Ein Thema von daddy · begonnen am 14. Jun 2024 · letzter Beitrag vom 17. Jun 2024
Antwort Antwort
Seite 2 von 2     12   
Benutzerbild von Sinspin
Sinspin

Registriert seit: 15. Sep 2008
Ort: Dubai
680 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields

  Alt 14. Jun 2024, 20:31
@ Sinspin
Mir ist natürlich klar, dass ich das Problem durch Änderungen in der Programmierung lösen kann. Es handelt sich aber um ein sehr umfangreiches Projekt und ich würde sehr viel Arbeit damit haben, alle Beziehungen dieser Art zu ändern. Ich bin einfach sehr überrascht, dass ein solch grober Fehler auch nach fast 20 Jahren noch in Delphi enthalten ist. Bin ich der Einzige der mit der genannten Konstellation von Komponenten arbeitet und Master/Detail-Beziehungen wie ursprünglich von Delphi vorgesehen nutzt?
Vermutlich weil das niemand so macht. Außer eventuell bei ganz einfachen Sachen.
Ich finde deine Methode erhlich gesagt faul.
Alle unsere Scripte müssen so gebaut sein das aus dem Script ersichtlich was mit wem zusammen hängt. Und zwar ohne das ich erst in der Komponente rumwühlen muss.
Ich rede auch nicht von einem Spielzeug Projekt. Das sind mehr als 600K eigene LOC mit mehr als 200 Dialogen.
Stefan
Nur die Besten sterben jung
A constant is a constant until it change.
  Mit Zitat antworten Zitat
Benutzerbild von Sinspin
Sinspin

Registriert seit: 15. Sep 2008
Ort: Dubai
680 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields

  Alt 14. Jun 2024, 20:38
Weiß jetzt nicht wie FireDAC arbeitet, aber bei pgDAC gibt es mehrere Modi.

* man gibt das/die Field(s) des Masters an und das/die Field(s) des Details ... das WHERE wird automatisch gebaut und angehängt
* man gibt das/die Field(s) des Masters an und das/die Param(s) des Details ... das WHERE ist manuell ins SELECT eingebaut
FireDAC kann auch Param(s) auto create. Solange der Master offen ist wenn man das Detail aufmacht. Also einfach das Script schreiben, MasterSource setzen. MasterFields eintragen, Details kann man leer lassen, und los geht es. Absolut simpel.
Stefan
Nur die Besten sterben jung
A constant is a constant until it change.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.453 Beiträge
 
Delphi 12 Athens
 
#13

AW: DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields

  Alt 14. Jun 2024, 23:18
FireDAC ist da ziemlich flexibel: Master-Detail Relationship (M/D)

Wichtig dabei ist dieser Abschnitt:
Zitat:
So how does it work? FireDAC builds for qOrderDetails a list of pairs - qOrders fields and qOrderDetails parameters. Elements in each pair:

When MasterFields is not specified, then they have the same name;
Otherwise, the pair elements have the same position, the same fields in the MasterFields list, and the same parameters in the Params collection.
When the current qOrders record is changed, FireDAC assigns for each parameter a corresponding field value. In our case, qOrderDetails :OrderID parameter gets the qOrder OrderID field value. After that, the qOrders is reexecuted.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
555 Beiträge
 
Delphi 10.3 Rio
 
#14

AW: DELPHI-Fehler in Master/Detail-Verknüfungem über MasterFields

  Alt 17. Jun 2024, 10:11
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?
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:09 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz