Inoffizielles deutsches Xbase-Forum

Hallo allerseits,

ich habe eine SQL-Tabelle mit statischem Cursor, z.B. 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.

DbGoto()?

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

Beim ADS? Welches Tabellenformat?

ADT.
Aber das dürfte unabhängig vom Tabellenformat sein, oder?

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 .

Uli

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 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: 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.

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!

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?

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.

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

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 ... .

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

SELECT SCOPE_IDENTITY()
SELECT @@IDENTITY

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.

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

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.

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 .
Danke für die Hilfe.