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

[SneakL8]

Hallo zusammen,

ich bin gerade dabei eine etwas ältere Anwendung von TAdsTable- auf TAdsQuery-Komponenten umzustellen. Leider stürzt mir die IDE in regelmäßigen Abständen ab, wenn ich die SQL-Eigentschaft im ADS-Editor ändere und auf Speichern klicke.
Mir scheint, dass es eine bestimmte Regelmäßigkeit gibt, wann die IDE abstürzt ("Delphi... funktioniert nicht mehr), bin aber noch nicht frauf gekommen, wann genau.
Hat jemand einen Tipp?

D7 inkl. SP
ADS 10.10.0.28

[haentschman]

Moin...
leider kann ich nichts zu D7 sagen.

Zitat:

eine etwas ältere Anwendung von TAdsTable- auf TAdsQuery-Komponenten umzustellen

Wenn du schon dabei bist, noch ein paar Tips die moderner sind :
1: Wenn möglich die SQL Statements nicht in der Komponente (DFM) speichern. Damit hast du auch dein Problem aus dem Weg.
2: Anlegen der SQL Statements im Quelltext in einer Unit oder einem Datenmodul. Nicht über den gesamten Quelltext verteilt.
3. Alternative zu 2.: Verlagern der SQL Statements nach extern. Siehe Tutorial: http://www.delphipraxis.net/49505-sq...einbinden.html
4: Verwenden von Parametern.

Delphi-Quellcode:

Query.SQL.Text := 'select from Universe where ID = :ID';
Query.ParamByName('ID').AsInteger := 0815;
Query.Open;

Auch wenn es als mehr Schreibaufwand erscheint... wenn du mal die Komponenten austauschen willst, wirst du es zu schätzen wissen.

[hoika]

Hallo,
ist denn Query.Active=True ?
(falls es sowas gibt bei den ADS-Komponenten gibt)

Das würde ich auf False stellen/lassen.

Ansonsten schließe ich mich meinem Vorschreiber an,
ausser 3. ...

[joachimd]

Wenn Du eh am umstellen bist ... meinst Du nicht, dass eine aktuelle Version besser wäre? Sowohl Delphi 7 als auch ADS 10 sind nicht mehr ganz so aktuell ...

[SneakL8]

Danke für die Tipps.

Ja, die Anwendung ist schon recht alt. Aber bei der Wahl "Modernisierung" oder "neue Kundenwünsche umsetzen", liegt die Priorität leider immer auf letzterem ...

Da es so klingt, als wenn der ADS bei SAP mehr für eine Beerdigung taugt als für eine Weiterentwicklung und nach ADS 12 angeblich nichts mehr kommt, stellt sich mir allerdings die Frage,ob man nicht gleich aus wans anderes wechselt...

Die Auslagerung der SQL-Statements ist auch ein guter Tipp, ich hatte da auch schon ein ungutes Gefühl.

Viele Grüße
Sneak-L8

[joachimd]

Du kannst den Property-Editor auch ausbauen, indem Du die ADS Designtime Packages selbst compilierst (IDE als Administrator starten) ... in der adsdesign.pas gibt es folgenden Eintrag:

Delphi-Quellcode:

    
RegisterPropertyEditor(TypeInfo(TStrings), TAdsQuery, 'Sql', TIDEQueryUtility);

Diesen ausblenden, compilieren, deinstallieren, installieren, fertig.

Schritte nochmals hier: https://www.jd-engineering.de/how-to...tor-in-delphi/

[himitsu]

Oder ein eigenes Package mit RegisterPropertyEditor(TypeInfo(TStrings), TAdsQuery, 'Sql', nil); , welches danach geladen wird (Abhänigkeit passend setzen)

Oder einen anderen TStrings-Editor angeben, der nicht abstürzt,

Oder den Bug bei den ADS-Leuten melden und auf 'nen Bugfix warten.

[joachimd]

Zitat von himitsu:

Oder den Bug bei den ADS-Leuten melden und auf 'nen Bugfix warten.

In einer schon längers nicht mehr unterstützten Version sehr unwahrscheinlich.

[RSF]

Zitat von joachimd:

Zitat von himitsu:

Oder den Bug bei den ADS-Leuten melden und auf 'nen Bugfix warten.

In einer schon längers nicht mehr unterstützten Version sehr unwahrscheinlich.

Sowie auch in der veralteten (aktuellen) Version 12.

[SneakL8]

Hallo zusammen, hallo @haentschman,

ich habe mir nochmal Gedanken gemacht zum Vorschlag, die SQL-Abfragen nicht in der Komponente zu speichern.

Dazu stellen sich mir folgende Fragen:

- Würdet Ihr von einer zentralen Stelle mit den SQL-Queries gleich eine Query-Komponente zurückgeben oder nur einen SQL-String für eine Komponente?
Der Vorteil wäre, dass ich beim Wechsel der Datenbank nur an zentraler Stelle die Komponenten-Erzeugung ändern muss und der Kompatibilität wegen aber immer ein TDataSet zurückgeben kann.
Nachteil wäre, dass ich (in der IDE) keine persistenten Felder mehr nutzen kann, an die ich z.B. Standard-AufbereitungsRoutinen (in OnGetText) hängen kann.
Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.
Ebenso müsste ich auf Lookup-Felder verzichten, aber das kann mit einem Join in SQL ja auch elegant gelöst werden. Nur bei berechneten Feldern sähe es schlecht aus.

- Auf dem Formular würde ich dann auch nur eine DataSource-Komponente anlegen und zur Laufzeit (z.B. im Create) von der zentralen Stelle eine Query-Komponente anfordern und mit einer DataSource verknüpfen?

- Wie würdet Ihr es mit Parametern für die Anfrage machen? Diese gleich in den SQL-String mit aufnehmen oder weiterhin als Parameter über ParamByValue und Co. definieren?
Hat das Einfluss auf die Performance der Abfrage, wenn sich die Werte zur Laufzeit ändern können?
Wenn weiterhin Parameter genutzt werden, würdet Ihr diese direkt vom zentralen Querybuilder bestücken lassen (Updates würden dann auch hierüber laufen) oder dies dem Formular überlassen?

- Wenn man den Parameter-Gedanken weiterspinnt, dann wäre es doch sinnvoll, für jede Abfrage eine eigene Routine zu machen, die ein Query liefert und konkret benannte und typisierte Werte entgegen nimmt. Andernfalls müsste ich immer die Parameter-Namen bzw. -Positionen nachschlagen

Sind meine Gedanken so nachvollziehbar? Oder bin ich da eher auf dem Holzweg?

Viele Grüße
Sneak-L8