Upsize und ISAM-Emulation

[Werner_Bayern]

sagt mal : hat jemand schon mal versucht aus der v9.x die libpq.dll umbenannt in libpqEX.dll und die zusammen mit

zu verwenden

Ja, führt zu einem Fehler beim

Code: Alles auswählen

DbeLoad("pgdbe") 

[ramses]

Ja, führt zu einem Fehler beim

Damit wurde meine Vermutung (auf die ich gewettet hätte) zur Gewissheit....

[ramses]

@ Tom

Hallo Tom

Obwohl ich dich nach deinen Erfahrungen mit der ISAM-Emu gefragt habe hast du noch nie dazu etwas geschrieben.

Wie sind denn deine Erfahrungen mit der ISAM-EMU?

[Werner_Bayern]

Ich muss da entschieden gegenhalten. Ja, die Behauptung, man müsse nur ein paar Zeilen Code umstellen, ist ein wenig optimistisch geraten, aber die ISAM-Emulation ist verwendbar, auch bei größeren Datenmengen. Wir haben Einzeltabellen mit mehreren hunderttausend Datensätzen, die sich auch in Browses gut bis sehr gut verhalten.

Servus Tom,

magst mal testen, wielange bei Dir sowas im ISAM-Modus mit einer Tabelle mit > 400k DS dauert?

Code: Alles auswählen

   static procedure insert
   local i, cZeit := time()

   for i := 1 to 100
      add_rec()
      replace art->text with "Insert-Test Nr. " + ltrim(str(i))
   next i
   confirmbox(, "Zeit für " + ltrim(str(i)) + " ISAM-Inserts: " + timediff(cZeit, time()))
   return

Wie geschrieben, dauert 6 Minuten (habs gerade nochmal getestet, diesmal sogar 7:30), wobei 1 DS 175 Felder hat. Ich weiß, das ist sehr viel und ich hab auch schon mal was von Relationen gehört
Hat bei uns historische Gründe und Relationen würden in diesem Fall nicht viel weniger Felder bringen, den Verwaltungsaufwand aber enorm erhöhen, vor allem auch für die externen Datenzugriffe auf die dbf.

[Tom]

Hallo, Carlo.

Ich knispel da schon seit etwas mehr als anderthalb, zwei Jahren ernsthaft mit herum (vorher hin und wieder), und so ungefähr seit Februar sind wir so weit, dass die Anwendung mit PGDBE und einigen Workarounds hier und da läuft, allerdings eingeschränkt (für einige Strukturen, die mit physikalischen Speicherorten und existierenden Dateien zu tun haben, haben wir noch keine Lösung gefunden, aber das würde jetzt zu weit führen). Mit dem neuesten Xbase++-Build laufen jetzt die Tests, dann wird es Rollouts an Betakunden geben. In unseren Netzen ist das recht performant und stabil, aber wir haben auch nur in Ausnahmefällen sehr große Datenmengen in einzelnen Tabellen. Das betrifft vor allem Protokollsysteme und einige medizinische Datenbanken. Die Bewegungsdatentabellen haben selten mehr als 10.000 Datensätze, da wir auch physikalisch Datenaufkommen monatsweise trennen (Planungssysteme).
Aber wir haben hier natürlich auch keinen Echtbetrieb.

So oder so. Sollte es noch hier und da Probleme geben, werden wir Lösungen finden. Der Ansatz erlaubt es ja, sanft zu migrieren. Dort, wo es problematisch ist, können wir im Code eingreifen - und das dann sukzessive ausbauen. Das ist ja auch die Idee hinter der PGDBE. Ich bin jedenfalls zuversichtlich.

[ramses]

Hallo Tom

Danke für deine Ansführungen.

Die Bewegungsdatentabellen haben selten mehr als 10.000 Datensätze

Jetzt sehe ich dass du gar nie in die Problemzonen kommst! Da kannst du auch zuversichtlich sein.

Ich habe eine Datenbank die trenne ich auch monatlich, die hat dann aber ca. 520'000 Sätze pro Monat.

[Tom]

Doch, mit einigen Daten schon, etwa Protokollsachen. Oder beispielsweise mit einer Tabelle, die alle in Deutschland erhältlichen Medikamente und Medizinprodukte enthält - die hat Fensterkreuz mal Pi ne Mio Datensätze. Beides (und ähnliches) wird aber nicht im klassischen Sinne gebraust (wozu sollte man auch in einem Browser eine Million Datensätze anzeigen?). Und die Medikamententabelle beispielsweise nimmt beim Upsizen natürlich ordentlich Zeit (aber mit dem neuesten Build auch nicht mehr so schlimm viel).

[AUGE_OHR]

magst mal testen, wielange bei Dir sowas im ISAM-Modus mit einer Tabelle mit > 400k DS dauert?

Code: Alles auswählen

   static procedure insert
   local i, cZeit := time()

   for i := 1 to 100
      add_rec()
      replace art->text with "Insert-Test Nr. " + ltrim(str(i))
   next i
   confirmbox(, "Zeit für " + ltrim(str(i)) + " ISAM-Inserts: " + timediff(cZeit, time()))
   return

Wie geschrieben, dauert 6 Minuten (habs gerade nochmal getestet, diesmal sogar 7:30),

hm ... das sind 100 x INSERT und dafür Minuten

bei mir sind es zwar nur 39 Felder aber native schaffe ich bei der Übertragung.

finish after 221.79 Sec. for 551403 Records = 2486.15

OK die "echten" Index Dateien fehlen dabei noch.
für das Text Feld der Bezeichnung brauch noch mal 4.48 Sek. für den Index.
ein Index für ein Numerisches Feld geht schneller in 1.78 Sek.

Dafür reduziert sich die Zeit bei ORDER BY bzw. "SEEK" auf 0.02 bzw 0.03 Sek.

--- Anmerkung ---
so langsam verstehe ich warum zu Phil Ide Class der HrTimer gehörte denn bei kleinen Table zeigt er nur noch 0.00 an
--- eof ---

ich kann nicht glauben das es bei der ISAM Emu Minuten braucht was native < 0.1 Sek. dauert und ihr euch damit Zufrieden gebt

[Werner_Bayern]

So, und hier noch der Echt-Test, so wie bei uns ein neuer, leerer Artikel angelegt wird:

Code: Alles auswählen

   static procedure insert
   local i, cZeit := time()

   for i := 1 to 100
      neuer_artikel()
      replace art->text with "Insert-Test Nr. " + ltrim(str(i))
   next i
   confirmbox(, "Zeit für " + ltrim(str(i)) + " ISAM-Inserts: " + timediff(cZeit, time()))
   return
   
function neuer_artikel
local nNr

dbClearfilter()
set order to 2
go bottom
nNr := art->art_nr + 1
set order to 1
if .not. add_rec()
   return .f.
endif
replace art->art_nr with nNr
replace art->datum with date()
replace art->datum_neu with date()
replace art->letzter_be with benutzer(,BENUTZER_NR)
replace art->angelegt with art->letzter_be
replace art->einheit with "Stk."
replace art->ust with 1
replace art->kennz with "N"
replace art->seriennr with "N"
commit 
return .t.

Das ist der bisherige DBF-Code. Klar, der Fall kommt bei uns nicht vor, dass mal eben 100 leere DS im Artikelstamm angelegt werden. Aber dieser Test hier dauert 12 Minuten, 53 Sekunden.

Mit 1 DS dauert es 3-4 Sekunden. Ist auch inakzeptabel.

[Werner_Bayern]

Beides (und ähnliches) wird aber nicht im klassischen Sinne gebraust (wozu sollte man auch in einem Browser eine Million Datensätze anzeigen?).

Artikel-Tabelle, Browse, Suchfeld. Klassische Vorgehensweise bei uns. Wieviele DS die hat, war bei DBF ziemlich egal, geht mittels Quickbrowse und Browse relativ flott. Es werden in beiden Fällen ja nicht die kompletten Daten eingelesen, was bei ISAM-SQL leider schon der Fall ist.

Was mir nicht klar ist: Warum ist da so ein großer Unterschied zwischen der ADS-Anbindung und der PG-ISAM-Anbindung? Beim ADS scheint ja grundsätzlich alles korrekt zu funktionieren... Bei der PG-ISAM haben wir hier nach 4 Jahren immer noch massive Inkompatibilitäten.

[ramses]

@Jimmy

ich kann nicht glauben das es bei der ISAM Emu Minuten braucht was native < 0.1 Sek. dauert und ihr euch damit Zufrieden gebt

Doch Jimmy leider ist es genau so. Zufrieden geben: Nein, gar nicht. Ich habe es begraben. Weil ich auch nicht sehe dass Alaska hier noch gross etwas ändern kann. Der massive Zeitverlust kommt von den Trigger und anderen speziellen Funktionen in der Datenbank welche die ISAM Emu benötigt um zu arbeiteten. SQL bietet vieles nicht was zur ISAM Emu nötig ist deshalb muss dies mit den speziellen Funktionen emuliert werden.

@Tom
Es ist schön dass die ISAM-EMU gut zu deiner Anwendung passt. Deine Medizin-Tabelle ist ja richtig statisch, aber deine Protokolltabelle hast du da einen ISAM Index drauf und nie Probleme/Wartezeiten beim Daten ansetzten?

@Werner
Der grosse unterschied sind die Funktionen die der SQL Server jedesmal abarbeiten muss wenn du über die ISAM-EMU etwas änderst. Besonders schlimm ist die Index Geschichte. Es gibt Sachen die lassen sich nicht Emulieren wenn die dazunötigen Grundlagen komplett fehlen und immer neu errechnet werden müssen. Das ADS das besser im Griff hat liegt unter vielem anderen auch daran dass dieser die Daten sequentiel hintereinander in einer einzigen Datei ablegt was Postgres eben nicht tut. ..... Wurde ADS nicht zuerst als DBF Ersatz für Clipper usw. entwickelt und deshalb schon alles nötige intus?

[Tom]

@Werner: Der ADS ist ganz anders gebaut und hat eine andere Geschichte. Die PGDBE setzt ISAM auf SQL um. Dafür muss einiges getan werden - u.a. muss eine Recordnumber (keine RowNumber, Jim) vorgehalten werden, die bei jedem INSERT aktualisiert werden muss, und dafür muss jedes Mal gezählt werden. Und noch einiges mehr. ISAM und SQL sind zwei völlig unterschiedliche Konzepte. Dass bei der Synchronisation hier und da ein bisschen verlorengeht - in diesem Fall an Performance -, liegt in der Natur dieser Sache. Wir können ja alle auf natives SQL umstellen. Oder nach und nach. Oder wir bauen Workarounds und warten auf Updates.

[Tom]

Kleiner Exkurs.

Wir sind von DBF & Co. u.a. gewöhnt, dass es eine konkrete, direkt für die Navigation verwendbare Datensatznummer gibt, die, Achtung, konsistent ist, und eineindeutig und jederzeit vorhanden. Jeder Datensatz hat genau eine Datensatznummer, die es genau einmal gibt. Die letzte Datensatznummer in einer Tabelle gibt zugleich die Bruttogröße der Tabelle an (also einschließlich der als gelöscht markierten Datensätze). Wenn eine sehr große Tabelle das im SQL-Umfeld nachbilden will, führt eigentlich kein Weg daran vorbei, das irgendwie zu pflegen, etwa über Stored Procs. Man kann auch nicht einfach irgendeinen Autoincrement nehmen oder so. Das ist die Hölle, würde ich einfach mal ins Grobe schätzen. Man muss im Prinzip dem Server die Kontrolle über die Datenbankintegrität entziehen, um das hinzukriegen. Und das kostet natürlich Zeit und Kraft. Aber ohne das gibt es keine ISAM-Emulation. Alle anderen Zugriffe - vor allem natives SQL - brauchen das nicht. Aber wenn wir das Navigationsumfeld auf SQL übertragen wollen, weil wir ohne große Codeänderungen von ISAM auf SQL wechseln wollen, dann ist es essentiell.

Und das ist nur ein Beispiel von sehr vielen. Das sind zwei Welten, die aufeinanderkrachen, und die Idee, diese Welten ohne Bruch miteinander zu verbinden, ist schon originell - und bewundernswert. Alaska ist allerdings nicht als erste auf diese Idee gekommen. Das gab es schon vorher in einigen Entwicklungssystemen, u.a. in FoxPro für MS-SQL. Auch das lief anfangs recht spröde. Aber es ist eben ein Ferrari, der auf einem Laster steht und diesen antreiben soll. Dass es da Reibungsverluste gibt, da muss man durch.

Und dabei geht es nicht darum, irgendwas "hinzunehmen". Natürlich ist fucking native SQL viel, viel schneller. Aber das ist doch nicht die Frage, um die es hier geht.

[Werner_Bayern]

ok, Danke für die Erklärungen.

Im Netz, normale DBF mit den 400k DS dauert übrigens mein 100facher insert mit Daten (neuer_artikel()) 5 Sekunden im Gegensatz zu 13 Minuten ISAM-SQL.

[Tom]

Weil es auch ein viel simplerer Vorgang ist. Datei sperren, Zähler hochsetzen, Blinddatensatz anhängen, popularisieren, ggf. noch Indexe aktualisieren, Datei entsperren. Das ganze ohne Rücksicht auf irgendwas. Aber um das Ergebnis dieses Vorgangs mit einem SQL-Server nachzustellen, der von sechs Vorgängen nur zwei überhaupt kennt, das kostet eben Kraft und Zeit.

[HaPe]

Hallo Tom !

Und das ist nur ein Beispiel von sehr vielen. Das sind zwei Welten, die aufeinanderkrachen, und die Idee, diese Welten ohne Bruch miteinander zu verbinden, ist schon originell - und bewundernswert. Alaska ist allerdings nicht als erste auf diese Idee gekommen. Das gab es schon vorher in einigen Entwicklungssystemen, u.a. in FoxPro für MS-SQL. Auch das lief anfangs recht spröde.

Kannst du dazu was näheres sagen?
Das habe ich noch nie gehört obwohl ich seit Clipper 87, Foxbase- und dBaseIII-Zeiten am Ball bin

PS: Für mich ist "FoxPro für MS-SQL" nur aus Neugierde interessant - ich habe meine VFP-Klassen auf Cursor-Adapter und SQL-Zugriff umgestellt. Man arbeitet mit einem lokalen Cursor (ist ähnlich wie DataObjects) der eine Teilmenge der Daten zieht, anzeigt, man ändern kann und dann wieder zurückschreibt.

[ramses]

Hallo zusammen

zum abrunden des ganzen.

Ich wollte es nun genau wissen und habe selbst ein Upsize Programm geschrieben.
Dieses Verwendet natives Postgres also nur die Funktionen der pglib.dll V11.0.3.19168 und eine selbstgeschriebene Klasse. Der PGServer PG 11.4 mit der selben Hardware und Server und Ursprungs DBF die ich auch für den weiter oben beschriebenen, nach 14 Stunden abgebrochenen Test mit Alaska-Upsize Tool verwendet habe.

Die Datenbank hat 535'072 Datensätze ein Datensatz mit allen Feldern ist 942 Bytes lang.
Die PG-Datenbank hat einen Index und ein Serial Feld.

Das Upsize DBF -> native PostgesTabelle benötige 303 Sekunden = 5 Min. 3 Sekunden PG Admin zeigte immer ca. 1700-1900 Transaktion/Sek an.

sql.jpg (20.6 KiB) 9170 mal betrachtet

Das Ansetzen von 100 Datensätzen benötigt 0.05 Sekunden.

Beide Werte haben mich, obwohl ich vorbereitet war doch erschreckt.

Weitere Versuche haben die Werte bestätigt. Die Datenbank habe ich noch mehrmals eingelesen. Durch das mehrfache einlesen hat die Datenbank nun mehrere Mio Datensätzte. Die Werte blieben immer gleich z.T. auch noch einige Sek. schneller. Eine Suche die daraus 36 Datensätze als Resultat übergibt benötigt 0.09 Sek.

Wieso soll ich mich da noch mit dem PG ISAM-EMU herumschlagen?
Und Wege Workarounds usw. suchen um z.B. eine Bestellung mit der PG ISAM-EMU in weniger als einer Minute zu speichern wenn es der Native Weg in 0.05 Sekunden schafft.

Nach diesem Versuch ist für mich der Weg den ich weiter gehe absolut klar.

Auch wenn es mehr Arbeit bedeutet die gewonne Perfomance macht allen Mehraufwand mehr als Wett.

[Tom]

Nochmal. Die PGDBE-ISAM-Emulation soll mit der DBFDBE konkurrieren, nicht mit nativen SQL.

[Werner_Bayern]

Weil es auch ein viel simplerer Vorgang ist. Datei sperren, Zähler hochsetzen, Blinddatensatz anhängen, popularisieren, ggf. noch Indexe aktualisieren, Datei entsperren. Das ganze ohne Rücksicht auf irgendwas. Aber um das Ergebnis dieses Vorgangs mit einem SQL-Server nachzustellen, der von sechs Vorgängen nur zwei überhaupt kennt, das kostet eben Kraft und Zeit.

Andererseits teilen sich da 2 Systeme den Vorgang, bei DBF macht (fast) alles der Client.

Fairerweise muss man dazu auch sagen, dass die ISAM-SQL-Geschichte mit steigender Anzahl an gleichzeitig aktiven Clients im Netz dann auch nicht mehr merkbar langsamer wird und man damit trotzdem die tatsächlichen Vorteile von SQL nutzen kann - z. B. das Erstellen eines neuen Indexes mittels

Code: Alles auswählen

create index ...

das auch bei 400k DS < 1 Sekunde dauert (ist dann aber kein ISAM-Index).
Man kann dann ja peu à peu seinen Code umstellen und optimieren. Gerade Reports machen ungemein Spaß, da kommt es schon mal vor, dass aus 50 Programmzeilen nur mehr 1 SQL-Abfrage wird, die noch dazu rasend schnell ist - und das im konkurrierenden Zugriff mittels ISAM-SQL.

[AUGE_OHR]

@Tom : es gibt ein internes FIELD "__Record"

---

wenn man ein FILTER oder SCOPE hat und eine Method o:GoToNumber() wo sollte er stehen bei

Code: Alles auswählen

o:GoToNumber(1)

1.) auf RECNO() = 1
2.) auf dem ersten Datensätz des FILTER / SCOPE

wer Lösung 1.) sagt "denkt" in xBase
wer Lösung 2.) sagt fängt an in SQL zu "denken"

also "Think SQL" und vergesst xBase den "das" ist das Problem in unseren Köpfen

---

Das die ISAM Emu so langsame ist haben wir nun bewiesen aber ich habe immer noch KEINEN Grund gehört warm man überhaupt ISAM mit SQL versenden soll. das Argument "damit man seinen alten Code" verwenden kann ist doch Quatsch wenn es um Faktor 100 langsamer ist.

vielmehr muss man den "alten" Code raus schmeissen was ich so mache

Code: Alles auswählen

#IFDEF __UsePG__

#ELSEIF __Clipper__

#ELSEIF __Harbour__

#ELSEIF __XPP__

#ENDIF

---

Ihr wartet Jahre lang darauf das Alaska die Arbeit für euch macht. Wieso glaubt Ihr den "Leeren" Versprechungen

Hat Alsaka einen PostgreSQL "Spezialisten" eingekauft der Wunder vollbringen kann
sicherlich hätte der nicht den FEHLER gemacht und Type "C" als "CHAR" zu nehmen sondern "TEXT"

solche FEHLER machen ANFÄNGER

---

Ein Entwickler hat immer das Problem das sein Werk in der Reatität laufen muss. Erst durch den Einsatz kann man die realen Problem erkennen. Anwortzeiten von > 1 Sek. sind NICHT akzeptabel. Das sage nicht Ich sondern der Kunde

Der Kunde wollte nicht mehr warten und deshalb hab ich nach eine alternativen Lösung gesucht.
Erst als ich mich in die native Lösung eingearbeitet hatte konnte ich der Geschwindigkeit Unterschied beurteilen.

Natürlich bin ich zunächst auch über fehlende ISAM Befehle gestolpert aber mit der Zeit merkte ich das ich solche Befehle NICHT brauche. Klar muss der Source "sauber" sein ... Spagetti-Code wo mittendrin Datenbank Aktionen sind ist dazu ungeeignet.

---

Ein Kunde hatte einen Cl*pper Programm Generator benutzt. der Code von "Gennifer" lies sich innerhalb 1 Woche nach native PostgreSQL portieren. Der Grund war der Aufbau des generierten Source wo eine strikte Trennung der Daten "In-" / "Out-" erfolgt so das ich nur an den beiden Stellen arbeiten musste.

---

Also zurück zu meiner Frage : "was" von der ISAM Emulation braucht man wirklich "wofür"

bitte keine "Vermutungen" sondern echte Fälle die bei euch mit der PgDBE auftreten und ihr keine anderen Lösungsweg seht.

[ramses]

Hallo Jimmy

Also zurück zu meiner Frage : "was" von der ISAM Emulation braucht man wirklich "wofür"

Der jetzt verwendete ADS soll durch PG ersetzt werden.
Ich habe auf die ISAM-EMU gewartet weil ich gehofft habe den Code 1:1 weiter benutzen zu können. Damit hätte ich vermeiden können Teil des Codes überarbeiten zu müssen. Eine änderung am Code bedeutet auch die Plicht zu umfassenden Tests, Dokumentation und Zertifizierung. Dies wollte ich vermeiden.

Entweder braucht man alles oder gar nichts von der ISAM-EMU. Im aktuellen Stand brauche ich gar nichts davon weil ich die gesetzten Ziele z.B. betreffend Performance oder keine Anpassungen damit gar nie erreichen kann.

Gedanklich habe ich die PGDBE jetzt unter den Teufelsstein(grosser historischer Stein) gelegt und überarbeite mit allem Aufwand und einer geänderten Denkweise den Code. Denn eine weite Bedingung ist in einigen bereichen bessere Performance als aktuell mit ADS.

Ihr wartet Jahre lang darauf das Alaska die Arbeit für euch macht. Wieso glaubt Ihr den "Leeren" Versprechungen

Ich wollte an Alaska's Aussagen glauben, sie wollen ja als verlässlicher Partner gesehen werden, zudem hoffte Ich der Umstieg geht so mit weniger eigenem Aufwand .....

sicherlich hätte der nicht den FEHLER gemacht und Type "C" als "CHAR" zu nehmen sondern "TEXT"

Das sehe gar nicht so. Wenn ISAM Emuliert werden soll muss sich auch das Datenfeld so verhalten. Soll heissen ein Feld darf nur die definierten Anzahl Zeichen aufnehmen. Verwendest du den Type Text gibt es kein Limit und der Code wäre gebrochen.

[AUGE_OHR]

Der jetzt verwendete ADS soll durch PG ersetzt werden.

und dafür brauchst du ISAM

wenn man mit SQL arbeiten will soll man auch in SQL "Denken" und nicht in xBase.
das ist IMHO der "Denk" Fehler beim Konzept der PgDBE den Alaska macht.

warum gibt es interne Index FIELD

meine Theorie :
wenn der xBase Index Ausdruck nur ein Feld enthält sollte es kein Problem sein
in xBase kann ich aber mehrere Felder im Index Ausdruck haben.
PostgreSQL v8.x lässt aber nur ein FIELD im Index zu ... was nun ...

Die Lösung von Alaska sind die internen FIELD wo der ganze String der Felder abgelegt wird um "einen" Index zu bilden.
nun gibt es da einen "Denk" Fehler denn unter SQL arbeitet ein Index "anders" !

bei einer Qwery "sucht" der SQL Server nach einem "passenden" Index der auf die erste ORDER BY Option "passt".
nun kann man bei ORDER BY noch weiter FIELD angeben so das es praktisch dem xBase Indexkey() entspricht.

mein "Upsize" für Index lautet die DBF mit allen Index öffnen und dann sich den Indexkey() von jedem Index holen.
zusammen mit dem DBF / Table Namen lese ich das ganze beim Starten in ein Array womit ich später meine Qwery zusammenbaue als Argumente für ORDER BY

also wofür brauch ich die Internen Index Felder

sicherlich hätte der nicht den FEHLER gemacht und Type "C" als "CHAR" zu nehmen sondern "TEXT"

das bezog sich auf PDR 7124 und "Full Text Search"

[Tom]

Mach doch bei Deinem Upsize, was Du willst, Jim, aber Du vergleichst hier Äpfel mit Glühbirnen. Nochmal, für Fußgänger: Die ISAM-Emulation ist für den Fall gedacht, dass man PG als direkten Ersatz für DBF verwenden will, weitgehend ohne Codeänderungen, ohne eigene Selects, ohne SQL eben. Für diesen Fall und nur für diesen Fall ist das gedacht, und für den funktioniert es auch. Es kann geschwindigkeitsmäßig nicht mit Pass-Through-SQL konkurrieren, es ist technisch aufwendig, generiert einen irren Overhead und so weiter. Aber das hat seinen Grund, das ist auch nötig, ohne das würde es nicht funktionieren. Ein Wechsel auf SQL ist eine andere Sache.

Kannst Du also bitte damit aufhören, hier diesen Qwatsch zu verklappen? Deine "Denkfehler"-Rätsel und all diesen Unsinn? Danke dafür.

[ramses]

Hallo Tom

Die ISAM-Emulation ist für den Fall gedacht, dass man PG als direkten Ersatz für DBF verwenden will,

Leider kann die ISAM Emu auch in diesem Fall bei der Geschwindikeit absolut nicht mit halten. Die DBFDBE schreibt Datensätze blitzartig weg, noch schneller als natives SQL, die ISAM-EMU benötigt für die selbe Aufgabe MInuten ...... Das ist ja das Problem.

[Tom]

Dem hat ja auch niemand widersprochen, Carlo. Bei großen Tabellen scheint es da noch ein wenig ... Optimierungsbedarf zu geben, falls sich das überhaupt machen lässt. Aber Jims Gezoppel geht ja in eine völlig andere Richtung, und wir reden hier über das, was das Threadthema besagt.