Delphi-PRAXiS
Seite 1 von 2  1 2   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Absturz des SQL-Editors in der IDE (D7/ADS10.1) (https://www.delphipraxis.net/191898-absturz-des-sql-editors-der-ide-d7-ads10-1-a.html)

SneakL8 1. Mär 2017 15:05

Datenbank: Advantage Database Server • Version: 10.1 • Zugriff über: Delphi 7

Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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 1. Mär 2017 15:48

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
Moin...:P
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 :wink::
1: Wenn möglich die SQL Statements nicht in der Komponente (DFM) speichern. Damit hast du auch dein Problem aus dem Weg. :P
2: Anlegen der SQL Statements im Quelltext in einer Unit oder einem Datenmodul. Nicht über den gesamten Quelltext verteilt. :zwinker:
3. Alternative zu 2.: Verlagern der SQL Statements nach extern. Siehe Tutorial: http://www.delphipraxis.net/49505-sq...einbinden.html
4: Verwenden von Parametern. :warn:
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. 8-)

hoika 1. Mär 2017 15:58

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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 1. Mär 2017 20:46

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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 3. Mär 2017 15:02

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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 4. Mär 2017 11:40

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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 4. Mär 2017 12:27

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
Oder ein eigenes Package mit
Delphi-Quellcode:
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 4. Mär 2017 16:07

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

Zitat von himitsu (Beitrag 1363186)
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 4. Mär 2017 22:15

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

Zitat von joachimd (Beitrag 1363195)
Zitat:

Zitat von himitsu (Beitrag 1363186)
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.:lol:

SneakL8 18. Mär 2017 14:37

AW: Absturz des SQL-Editors in der IDE (D7/ADS10.1)
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:35 Uhr.
Seite 1 von 2  1 2   

Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf