Lücken in fortlaufender Nummerierung finden

[jobo]

ot

Zitat:

Zitat von Neutral General (Beitrag 1330525)

Würde es für Paradox ne SQL-Lösung geben wäre die auch sehr wahrscheinlich schneller als eine in Delphi.
War also keine schlechte Idee nach SQL zu fragen bzw. es mit SQL zu versuchen.

Ich denke, das ist genau das Problem, auf das Uwe hinweisen wollte. Der "Server" von Paradox ist immer(!) der eigene PC. Idealerweise liegt das Datenfile lokal und es gibt keinen Netzwerkzugriff /-transport.
Das SQL wird vermutlich eh von der BDE in sequentielle Zugriffe umgebaut, mein eigener Hinweis bezüglich not exists versus outer join ist ja auch fragwürdig bei dieser Art File DB.

SQL=schneller als per Clientprogrammierung finde ich auch immer eine gute Idee, gilt m.E. nur wenn tatsächlich ein echter Server im Spiel ist.
/ot

[Uwe Raabe]

Ich habe den Code nochmal etwas umgebaut, da der erste Datensatz überflüssigerweise zweimal überprüft wurde. Zusätzlich habe ich noch ein Begin/Endupdate auf Target eingebaut.

Leider habe ich gerade keine richtig große Paradox-Tabelle da, aber auf meinem System schafft diese Methode die 4500 Sätze in 5 ms.

[hoika]

Hallo,
wenn es nur eine Tabelle ist, dann wirklich lokal machen mit 2 String-Listen.

LocalSQL auf eine Paradox-Tabelle (Achtung, also keine Generatoren möglich)
würde ich sein lassen, das ist furchtbar langsam (naja, kommt auf die Tabelle und die SQL-Anweisung an).

Noch eine Frage zu den Lücken:
Auch das AutoInc erzeugt doch Lücken beim Löschen,
oder hast du standardmäßig keine Datensätze gelöscht?

Paradox:
index out of date
blob has been modified

Gott sei dank ich bin da weg ;)


Heiko