Absturz des SQL-Editors in der IDE (D7/ADS10.1)

[SneakL8]

Hallo zusammen,

und wieder herzlichen Dank an @haentschman für Deine Ausführungen.

Ich habe mich jetzt drangemacht und mal alle neuen TAdsQuerys aus den Formularen rausgeworfen und eine QueryBuilder-Klasse gebaut.

Ich hab mich jetzt mal für ein Interface (IDataSet) entschieden, das nur ein paar Sachen aus TDataSet enthält und sonst neue für mich praktische Funktionen (z.B. ein Refresh, das sich bei einem statischen Cursor den aktuellen Satz merkt, und nach Close/Open zu diesem zurückkehrt, damit man vom Update nichts sieht, solange die Datenbasis unverändert bleibt) einführt.
Auf TDataSource und datensensitive Felder habe ich im ersten Schritt noch nicht verzichtet, um nicht gleich alles bisherige umzuwerfen.

Über die Builder-Technik baue ich mir die Daten auf:
TMyQueryBuilder.GetQueryKunde(self, Kunden).LinkTo(MyDataSource).LockForEdit;

Eigentlich wollte ich dann das zurückgegebe IDataSet auch in einer Variable im Form speichern, damit ich später darauf zugreifen kann. Doch da habe ich die Rechnung ohne IntfClear gemacht und mir nette Speicherzugriffsfehler eingehandelt. Jetzt gebe ich erstmal ein TDataSet zurück. Ganz auch eine Variable im Formular verzichten klappt leider noch nicht, weil ich z.B. noch ein xxx.Post; absetzen will, wenn das Formular zum Ändern von Daten dient und ich (noch) datensensitive Elemente nutze.

Aber mich beschäftigt das Interface trotzdem. Nach Studium von Google (bzw. seinen Suchtreffern) scheint es mir so, dass ich irgendwo noch auf die IDataSet-Variable zugreife, nachdem das TDataSet bereits freigegeben wurde. Ich bin aber der Meinung, dass ich die Variablen rechtzeitig vor dem Release des TDataSets freigebe (Zuweisung von nil), also spätestens im Destroy des Formulars (vor dem inherited). Das scheint aber nicht zu klappen.
Habt Ihr da vielleicht einen Tipp für mich? Oder passt das alles und ich hab nur irgend eine Variable übersehen?

Ansonsten fühlt sich die Sache mit der Trennung der DataSets/Queries und dem Formular gut an. Selbst die Formatierung der Felder (DisplayName, DisplayFormat oder OnGettext/OnSetText) kann ich ja in der GetQuery-Methode nach dem Open mittels FieldByName('xxx').DisplayName := 'xxx' machen. Dadurch ist es nochmal leichter, Formular und Datenkomponente zu trennen. Und ich kann die Aufbereitung a) zentral und b) direkt beim Query-String machen, so ist alles schön bei einander. Wobei ich mir DisplayName auch sparen kann, indem ich im select-Statement gleich ein 'as "xxx"' hinter die zu lesenden Felder packe...

Viele Grüße
Sneak-L8

[Rollo62]

Hallo haentschman,

wenn du Alle Komponenten rausgeworfen hast und nur normale Komponenten mit der DB verknüppelst liegt es Nahe das du das mal mit LiveBindings versucht hast.
Die sind ja eingentlich für die Bindung von DB zu Komponente gemacht, und bei einfachen Label, Edit, etc. sollte das doch auch gut funktionieren.

Arbeitest du auch damit, oder machst du da komplett deinen eigenen Layer drum ?
Ich fände es wünschenswert mal ein schönes BestPractices Beispiel mit LiveBinding in Code zu sehen, in einer
echten Anwendung.
Steven Ball hat da ja eine schöne Serie zu gemacht, aber mir fehlt immer noch der Ansatz wie man das in größeren Projekten anlegen sollte.


Rollo

[haentschman]

Moin...

Zitat:

wenn du Alle Komponenten rausgeworfen hast und nur normale Komponenten mit der DB verknüppelst liegt es Nahe das du das mal mit LiveBindings versucht hast.

...und dann wieder begraben.
Thread: http://www.delphipraxis.net/190711-l...ceadapter.html

Zitat:

Arbeitest du auch damit, oder machst du da komplett deinen eigenen Layer drum ?

Ich arbeite mit Objekten in Objektlisten und Interfaces als "Zwischenschicht" zur Datenbank. Für jedes DBMS gibt es ein spezielles Interface. Die Anwendung arbeitet mit dem Interface. Die Anbindung der Objekte aus der Liste funktioniert klassisch nach Bedarf.

Die Livebindings haben mir keinen Mehrwert gebracht...

[Rollo62]

Für das Füllen und Reagieren auf Änderungen musst du dann Alles von Hand verknüpfen und hast du zu jeder Komponente einen "Wrapper" der das bidirektional erledigt ?
Oder benutzt du dafür auch schon RTTI oder das Spring4D Framework ?

Das sollte eigentlich ja LiveBindings leisten, so das man einfach DB mit dem View verbinden kann.
Warum genau hast du dich gegen LB entschieden, war es die Performance, oder die Stabilität ?
Ich möchte den LB Gedanken noch nicht komplett über Bord werfen

Rollo

[haentschman]

Moin...

Zitat:

Für das Füllen und Reagieren auf Änderungen musst du dann Alles von Hand verknüpfen

...ja. Da gehört eigentlich noch mehr dazu...
sinngemäß: Beispiel an einem Frame:
1. Dem Frame wird das Objekt was es anzuzeigen gilt übergeben.
2. Vom Objekt wird eine Kopie erstellt. (neue Instanz)
3. Der Frame arbeitet mit der Kopie. (zurücksetzen möglich etc.).
4. In den klassischen OnChange werden die Änderungen in die Kopie geschrieben.
5. Speichern NEIN: Die Kopie wird weggeräumt...
6. Speichern JA: Über Assign des Originalobjektes werden die Werte übertragen. Die Kopie wird weggeräumt...
...fertsch. Klar ist das mehr Arbeit. Aber man hat die Kontrolle...

Zitat:

Das sollte eigentlich ja LiveBindings leisten, so das man einfach DB mit dem View verbinden kann.
Warum genau hast du dich gegen LB entschieden, war es die Performance, oder die Stabilität ?

...versuche mal ohne Code mit LB ein Objekt aus einer Liste an ein ListviewItem oder einen Combobox Eintrag zu hängen. Klassisch wäre das ein Einzeiler.