Refresh bei Sql-Tabellen

Advantage Database Server

Moderator: Moderatoren

Antworten
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 14:22

Hallo allerseits,

ich habe eine SQL-Tabelle mit statischem Cursor, z.B.

Code: Alles auswählen

select A.*,AP.Betreff
from Auftrag A
inner join AuftragsPosition AP on AP.AId = A.AId
Jetzt haben sich die Daten geändert und ich muß deshalb den statischen Cursor neu erzeugen.
Anschließend möchte ich wieder auf dem gleichen Datensatz stehen. Ich habe dafür zwei Lösungen: entweder Einsatz von Locate oder Einsatz von einem Temporären Filter. Dabei merke ich mir vorher eine eindeutige Id-Kombination, z.B. AId und APId.
Locate ist dabei gähnend langsam. Der temporäre Filter ist manchmal schnell aber nicht immer.

Gibt es beim ADS eine andere schnellere Lösung? (ADS 12.0 ist im Einsatz)

Edit: Gramatikfehler korrigiert.
Zuletzt geändert von UliTs am Di, 20. Mär 2018 14:27, insgesamt 1-mal geändert.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7090
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von Tom » Di, 20. Mär 2018 14:26

DbGoto()?
Herzlich,
Tom

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 14:28

Dafür braucht man aber eine RecNo().
Und die ist doch bei statischen SQL-Cursor nicht unbedingt gleich, oder?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7090
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von Tom » Di, 20. Mär 2018 14:34

Beim ADS? Welches Tabellenformat?
Herzlich,
Tom

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 14:42

ADT.
Aber das dürfte unabhängig vom Tabellenformat sein, oder?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 14:49

Aber ist vielleicht doch eine gute Idee!
Ich werde es mit DbGoto() probieren und anschließend prüfen, ob es der gleiche Datensatz ist.
Und wenn nicht: kann ich immer noch den Filter anwenden :D .

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
nightcrawler
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 293
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72181 Starzach
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von nightcrawler » Di, 20. Mär 2018 16:21

Du hast ein INNER JOIN - ist es wirklich eine mehrdeutige Auflösung, d.h. Du hast die gleiche Position in mehreren Aufträgen und den gleichen Auftrag in mehreren Positionen? Falls nicht, selektiere AP.ROWID mit. Die ROWID ist virtuell und für jede Tabelle eindeutig. Dann kannst Du nach einem Schließen/Öffnen wieder darauf positionieren.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 23:39

Ich habe mich zunächst mit Joachim's Vorschlag beschäftigt. Leider ist der Filter auf die RowId auch langsam :-( .
Dabei fiel mir noch folgendes auf: das Beispiel entspricht nicht dem in meinem Programm. Es muß Left Outer Join statt Inner Join heißen und außerdem wird noch eine PosNr abgefragt:

Code: Alles auswählen

select A.*,AP.Betreff
from Auftrag A
left outer join AuftragsPosition AP on AP.AId = A.AId and AP.PosNr=1
Das heisst, die SQL-Tabelle ist mit der Tabelle Auftrag bis auf die Spalte AP.Betreff identisch.
-
Unabhängig davon probiere ich auch Tom's Lösungsansatz aus.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 20. Mär 2018 23:56

Also mit bekomme ich es in diesem Fall schnell hin. Leider aber noch nicht immer ...
Mache morgen weiter

P.S. schon einmal Danke für die Hilfe!
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Mo, 26. Mär 2018 15:26

nightcrawler hat geschrieben:
Di, 20. Mär 2018 16:21
Du hast ein INNER JOIN - ist es wirklich eine mehrdeutige Auflösung, d.h. Du hast die gleiche Position in mehreren Aufträgen und den gleichen Auftrag in mehreren Positionen? Falls nicht, selektiere AP.ROWID mit. Die ROWID ist virtuell und für jede Tabelle eindeutig. Dann kannst Du nach einem Schließen/Öffnen wieder darauf positionieren.
Ich habe es mit der ROWID versucht. Das Positionieren kann ich ja über
Locate
oder
set filter mit anschließendem gotop und löschen des Filters
machen. So ist es aber auch mit der ROWID zu langsam. Kann ich das Positionieren mittels ROWID auch geschickter machen?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
nightcrawler
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 293
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72181 Starzach
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von nightcrawler » Mo, 26. Mär 2018 15:29

Hallo Uli,
das Schnellste ist ein eindeutiger Schlüssel mit einem Index drauf. Deshalb auch vorhin die Frage nach n:m oder 1:n. Bei 1:n hast Du die ID der ersten Tabelle und kannst direkt darauf positionieren. Selbst bei n:m kannst Du ein Locate auf beide IDs machen.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Mo, 26. Mär 2018 15:41

nightcrawler hat geschrieben:
Mo, 26. Mär 2018 15:29
Hallo Uli,
das Schnellste ist ein eindeutiger Schlüssel mit einem Index drauf. Deshalb auch vorhin die Frage nach n:m oder 1:n. Bei 1:n hast Du die ID der ersten Tabelle und kannst direkt darauf positionieren. Selbst bei n:m kannst Du ein Locate auf beide IDs machen.
Danke für die schnelle Reaktion. Mit direkt darauf positionieren meinst du "Goto"? Ich schau noch einmal, warum es (unverständlicherweise) immer noch langsam ist.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 10. Apr 2018 14:58

So, ich habe mich heute noch einmal (viel zu lange...) damit beschäftigt.
Es scheint so zu sein, dass -sobald ich einen Goto-, Filter- oder Locate-Befehl einsetze, dass Sql-Statement vorher vollständig berechnet wird. Ich habe bisher keine Möglichkeit gefunden, es zu beschleunigen ... :-( .
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 784
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von satmax » Di, 10. Apr 2018 15:24

Habs nur kurz überflogen und leider keine Zeit, schon mal versucht:

SELECT SCOPE_IDENTITY()
SELECT @@IDENTITY
Gruß
Markus

Benutzeravatar
HaPe
Foren-Moderator
Foren-Moderator
Beiträge: 432
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz

Re: Refresh bei Sql-Tabellen

Beitrag von HaPe » Di, 10. Apr 2018 15:44

Hallo Uli !
Ich habe bisher keine Möglichkeit gefunden, es zu beschleunigen ... :-(
Mit welchem Treiber von Xbase++ greifst du auf den ADS zu?
- Mit der ADSDBE?
- Über ODBCDBE?

Wenn du bisher den ersten verwendet hast, probiers doch mal mit dem zweiten.
Vielleicht hat da Alaska selbst nicht ganz so viel "dran rum gefummelt" wegen der CLIPPER-Kompatibilität.
--
Hans-Peter

Organisator der XUG Stuttgart
Beisitzer des Deutschsprachige Xbase-Entwickler e. V.

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Di, 10. Apr 2018 15:55

Hallo Satmax,

ich habe mal nach "Scope_Identity" in der ADS-Beschreibung gesucht aber nichts gefunden.
HaPe hat geschrieben:
Di, 10. Apr 2018 15:44
Hallo Uli !
Mit welchem Treiber von Xbase++ greifst du auf den ADS zu?
- Mit der ADSDBE?
- Über ODBCDBE?
Hallo Hans-Peter,
ich benutze keinen der beiden Treiber sondern die AceServer-Klasse von Friedhelm mit Direkt-Zugriffen auf die DLLs.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 784
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von satmax » Di, 10. Apr 2018 18:55

UliTs hat geschrieben:
Di, 10. Apr 2018 15:55
Hallo Satmax,

ich habe mal nach "Scope_Identity" in der ADS-Beschreibung gesucht aber nichts gefunden.
Ups, nicht aufgepasst und nur SQL gelesen. Kommt vom MS SQL Server, nicht von ADS.
Gruß
Markus

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2517
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: Refresh bei Sql-Tabellen

Beitrag von UliTs » Mi, 11. Apr 2018 11:11

UliTs hat geschrieben:
Di, 10. Apr 2018 14:58
So, ich habe mich heute noch einmal (viel zu lange...) damit beschäftigt.
Es scheint so zu sein, dass -sobald ich einen Goto-, Filter- oder Locate-Befehl einsetze, dass Sql-Statement vorher vollständig berechnet wird. Ich habe bisher keine Möglichkeit gefunden, es zu beschleunigen ... :-( .
Ich habe jetzt eine in meinem Fall zufriedenstellende Lösung gefunden, um den Cursor nach erneutem Öffnen der Tabelle zu positionieren. Da in 99% der Fälle der Cursor auf einem der ersten Datensätze steht, durchsuche ich die ersten (250) Datensätze mittels Skip(1) und Prüfung des eindeutigen Schlüssels. Erst wenn ich ihn so nicht gefunden habe, mache ich ein Locate() :-) . Ergebnis: rasend schnell :D .
Danke für die Hilfe.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Antworten