Upsize und ISAM-Emulation

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Upsize und ISAM-Emulation

Beitrag von Werner_Bayern »

Ich verlagere das Thema jetzt mal hierher, meine Antwort bezieht sich ungefähr ab dieser Stelle darauf: viewtopic.php?p=128897#p128897

Carlo, das Upsize wie vorhin beschrieben auf unseren PG 11.2 auf einem unserer virtuellen Server übers LAN dauert genau 47 Minuten. Artikel-Dbf mit 400700 DS und 6 Index-Dateien, Adressen mit 3 Index-Dateien.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Upsize und ISAM-Emulation

Beitrag von HaPe »

Hallo Zusammen !

Entweder hab ichs überlesen oder habe Tomaten auf den Augen.
Ist man beim DBF-Upsize auf PostgreSQL und ISAM-Emulation auf ein bestimmtes Vorgehen von Alaska angewiesen?

Bei großen (ok, was ist schon groß) Datenmengen importiert man immer ohne Index. Nach dem Import erstellt man dann die Indexdateien sauber neu.
Für SQL-Server verwende ich das Tool XCase das Stored Procedures zur Erstellung der Indizes anhand der vorherigen DBF erstellt. Dann hat man diese im Notfall immer zur Hand.

Beim $MS-SQL-Server gibt es einen Bulk-Insert, da gehen 100erte von MB in ein paar Minuten.
Zum Teil erstellt man CSV-Dateien aus den DBFs und Schwuppdiwupp sind die Daten drin ...
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Hans Peter,

es gibt ein Upsize-Tool von Alaska. Das den Vorteil hat alle Strukturen neben den "normalen" Tabellenfeldern automatisch mit anzulegen. Also alles was z. B. für ein RecNo(), DbSkip(), etc. notwendig ist, oder für die Indizes. Der baut daraus Zusatzfelder, Stored Procedures, Trigger, etc. Also viel mehr als einfach nur einen Import der Daten in gleichlautende Felder einer SQL-Datenbank.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Upsize und ISAM-Emulation

Beitrag von HaPe »

Hallo Jan !
es gibt ein Upsize-Tool von Alaska.
Ok, wieder was gelernt :lol:
--
Hans-Peter
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Werner

Danke für deine Eckdaten. Ich habe die Sache eigentlich schon endgültig beerdigt. Da diese Eckdaten von dir und nicht aus der Werbung stammen grabe ich die ganze Sache nun nochmals aus starte einige weitere Versuche.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Hallo, Hans-Peter.

Ohne das Upsize-Tool gibt's überhaupt keine ISAM-Emulation. Daten migrieren kann man - u.a. nach PostGre - auch auf andere Arten, aber alles, was dranhängt, macht nur das Tool. Beziehungsweise macht man das unter einer eigenen Oberfläche unter Verwendung der Upsize-Funktionen.
Herzlich,
Tom
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern »

Carlo,

hab jetzt das Einfügen von 100 DS in meine Artikel.dbf (175 Felder, 400k DS!) im ISAM-Modus mit unserem PG-Server im Netz getestet: 6 Minuten! :(

6 DS benötigten 55 Sekunden. Leider klares Fazit (wie auch schon in meinem Vortrag): ISAM-SQL mit großen Datenmengen und Feldern: Untauglich.

Auch sind viele Dinge einfach nicht kompatibel:
  • Quickbrowse mit großen Datenmengen komplett fehlerhaft
  • Suche in einem XbpBrowse mittels dbseek() und :refreshAll() funktioniert nicht
  • Vertikaler Scrollbalken im Browse wird falsch angezeigt
  • Browse verhält sich generell anders im ISAM-Modus
  • Aktualität im Netz von DS nach Änderungen ist nicht gegeben
Eine Umstellung von DBF auf ISAM-SQL wäre bei uns also doch mit sehr umfangreichen Codeänderungen verbunden...

Wir bleiben also dabei: Neues wird über Pass-Through gemacht, alter Code wird auf Pass-Through umgestellt, wenn Zeit ist oder die Notwendigkeit besteht.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

moin,

die Frage ist : "was" von der PgDBE ISAM Emulation braucht man wirklich :?:

1.) xBase Index
2.) SKIP
3.) SEEK, FILTER bzw SCOPE ...
4.) PostgreSQL Index

---

ad 1.) ein Index dient ja Primär der Sortierung. bei SQL gibt es "ORDER BY"

ad 2.) SKIP ist wohl ein Befehl den ich nur im DbSkipper() mit DBF benutze.
für ein Array oder Object benötigt man auch den o:skipBlock aber eben kein SKIP

ad 3.) den SEEK / FILTER / SCOPE Ausdruck muss man durch einen WHERE Ausdruck ersetzten.

ich benutzte dazu PgAdmnin wo ich die SQL Query so lange ausprobiere bis mir das Ergebnis passt.

ad 4.) bei einem ORDER BY versucht ein SQL Server den "passenden" Index, wenn welche existieren, selbst zu einer Query zu finden.
da die Anzahl von Indexen bei SQL "unbegrenzt" ist könnte man für jede Abfrage einen Index anlegen ...

ohne einen passenden PostgreSQL Index dauert es eine Zeit wobei die Grösse der Table eine Rolle spielt.

bei meiner Artikel Table mit 4439 Sätzen dauert es 0.02 Sec. und nach weiteren 0.09 Sec. steht das Browse
bei klick auf den Column Header ändert er also die Sortierung in ca. 1/10 Sek

bei 500000 Sätzen sieht es da schon viel schlechter aus. da können ohne "echten" PostgreSQL Index schon mal paar Sekunden vergehen

---

also zurück zu meiner Frage : "was" von der ISAM Emulation braucht man wirklich :?:
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Man braucht sie, um mit demselben Code weiterarbeiten zu können, Jim.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Werner

DANKE DANKE DANKE

Du bestätigst mir meine Worte und Tests mit noch viel, sehr viel schlechterm Ergebnis.

Nach deinen vorletztem Beitrag habe das ganze wie geschieben erneut ausgegraben und getestet.
Um alle Zweifel auszuschliessen Postgres sogar extra auf einem Windows Server installiert.
(Postgres und die Datenbestände sind sonst aus Sicherheits- und funkionellen Gründen ausschliesslich auf FreeBSD Servern)
Es sollen ja verglichbare Systeme und Resultate sein.

Das Upsize einer Datenbank mit einem Index läuft nun nach 13 Stunden noch immer.
Nachdem du mir mit deinen Zahlen (die noch schlechter waren als meine Werte) das Verhalten der PG ISAM-EMU bestätigt hast breche ich die übung nun definiv ab.
Das Upsize hat in den 13 Stunden auf dem Windowsserver (4 Kerne) ca. 90% CPU Last verursacht, zu beginn ca. 30 Datensätze/Sek. geschafft
die dann schnell auf ca. 10 Datensätze/Sek. abgefallen sind. Die Performance PG auf Windows ist wesentlich schlechter als unter FreeBSD.

Es macht keinen Sinn noch länger auf mein Upsize zu warten. Denn auch wenn das Upszize durchgelaufen wäre, sogar mit Zwangsferien in den Betrieben um die Daten zu konvertierten ist das
verhalten der PG-ISAM-EMU absolut unbenutzbar. Kein Benutzer aktzeptiert es 1 Minute vor dem PC zu warten bis die Datenbank 1 Bestellung gespeichert hat. Und deine Werte waren noch um ein vielfaches schlechter.
Dazu kommen noch die wie von dir beschrieben äusserst krassen sonstigen Mängel, wobei besondern der die "Aktualität im Netz von DS nach Änderungen ist nicht gegeben" den Schweregrad 10von10, Desaster-Unbenutzbar, Lebensgefahr aufweist.
Selbst die PQLib 8.3. (Schnittstelle zu PG) die Alaska verwendet ist EOL was auch bei Pass-Through zu einigen Sorgen führt.

Wir bleiben also dabei: Neues wird über Nativ-Postgres gemacht, alter Code wird auf Nativ-Postgres umgestellt, wenn Zeit ist oder die Notwendigkeit besteht.

Ich begrabe die PG-DBE erneut. Nur diesmal noch tiefer. Man sollte noch den Teufelsfelsen darauf stellen. (Um sicherzustellen nicht nocheinmal in Versuchung zu geraten.)

Diese Erkenntnisse haben mich über 1000 Euro gekostet (verlängerung Sub.) die ich eigentlich hauptsächlich nur wegen der Ankündigung der "neuen" PG gekauft habe. Dennoch bin ich froh darüber.
Zeigt dies doch dass ich mit dem Nativen Postgres auf dem richtigen Weg bin, auch wenn er aufweniger ist als Pass-Through und sehr viel aufweniger als die ISAM Variante.
So hat damit bis jetzt immer alles dauerhaft funktioniert was bei Pass-Through nicht immer der Fall war und bei ISAM schon gar nicht.

Zudem geht Alaska beim Upsize den falschen Weg. Das Upsize erstellt jetzt die Datenbank und Index zusammen, würde zuerst die Datenbank übertragen und danach der Index erstellt wäre Upsize um einiges schneller.

Fazit: Bei Alaska hat sich nichts geändert. Ich hätte es wirklich gerne anders erlebt.

RIP PG-ISAM-EMU
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

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. Das Upsize dauert bei einer lebenden Datenmenge in etwa so lange wie eine klassische Reindexierung nebst DbPack(). Außerdem braucht man das je Datenbank nur einmal. Und man muss einige Abläufe anpassen, das ist ebenfalls klar. Man kann z.B. den InString-Operator ($) im Moment mit der PGDBE nicht in Filterausdrücken verwenden, und die Sache mit dem DELETED ON und Standard-Navigationscodeblöcken im XbpBrowse ist auch noch nicht geklärt. Aber ich bleibe bei meinen 95 Prozent. Gleichzeitig habe ich die Chance, den Code drastisch zu optimieren, und zwar selbst für den Fall, dass ich mehrere DBEs alternativ einsetze.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Tom
die ISAM-Emulation ist verwendbar // Aber ich bleibe bei meinen 95 Prozent. Gleichzeitig habe ich die Chance, den Code drastisch zu optimieren, und zwar selbst für den Fall, dass ich mehrere DBEs alternativ einsetze.
Im Sinn des Worts hast du natürlich Recht: die ISAM-Emulation ist verwendbar.

Nur wie? Schau nur mal Werners Aufstellung, die ist nicht mal abschliessend.

"95 Prozent" bedeutet doch auch dass 5 Prozent Probleme bleiben.
Etwas Umstellen und dann 5 Prozent Probleme haben geht doch nicht! Ich mag mir die Folgen gar nicht vorstellen.
Ich finde es persönlich unrealistisch oder Wunschdenken ein Programm für mehrere DBE's auszulegen und zu optimieren.
(ADSDBE und DBFDBE ausgenommen)
Das macht nicht nur viel mehr Arbeit, ist auch sehr viel schwieriger zu Unterhalten usw.
Natürlich, bei ADS würde ich dir Recht geben, der kostet ja sofort sehr viel.
Postgres ist dagegen kostenlos. Ein Programm auf eine DBE zu optimieren ist nicht nur sehr viel schneller erstellt, du kannst alle spezifischen möglichkeiten einer DBE voll und ganz ausnutzen ohne kompromisse einzugehen. Es, das Programm ist dadurch auch wartungsarmer und damit viel Problemloser. Ob's der Markt wirklich verlangt, mehrere DBE's wer weiss.....

Kein Benutzer aktzeptiert es 1 Minute vor dem PC zu warten bis die Datenbank 1 Bestellung gespeichert hat --> also ist die ISAM-Emu nicht verwendbar.
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Tom hat geschrieben: Mi, 03. Jul 2019 7:23 Man braucht sie, um mit demselben Code weiterarbeiten zu können, Jim.
das man seinen Code "optimieren" muss darüber sind wir uns ja einig.
wie viel vom "alten" Code dann übrig bleibt darauf will ich hinaus.

---

ich habe ja nun die Punkte aufgelistet die mit bei ISAM eingefallen sind und kein Punkt ist IMHO notwendig für PostgreSQL :!:

man muss nur ein wenig weiter denken ... nehmen wir ein SKIP was man z.b. in einer WHILE !EOF() Schleife hat.
wenn ich nun eine SQL Query erstelle "verschwindet" das SKIP ... ich bekomme im Result-Set ja alle betreffende Sätze.

oder Sx_KeyGoto() von SixDrive wenn ein SCOPE gesetzt war ... das selbe kann man mit row_number() erreichen.

JA ... es wird Code geben wo es schwer ist das ganz "aufzulösen" aber alter Code mit der PgDBE Emulation ist einfach unerträglich langsam :angry4:

---

Ich habe eine Vermutung warum Alaska die internen FIELD für den Index eingeführt hat.

unter PostgreSQL v8.x konnte man einen "echten" Index nur auf ein FIELD machen

Code: Alles auswählen

CREATE INDEX cIndex_Name ON cTable_Name (cField_Name)
unter xBase kann ich aber einen Index über mehrere Felder machen und solche xBase Indexe konnte man nicht "übersetzten"

bei der PostgreSQL v9.x Version wurde das nun erweitert auf 2 x FIELD

Code: Alles auswählen

CREATE INDEX cIndex_Name ON cTable_Name (cField_Name1, cField_Name2 )
man kann auch eine Function verwenden aber dann nur mit 1 x FIELD

Code: Alles auswählen

CREATE INDEX cIndex_Name ON cTable_Name ( lower(cField_Name) )
auf der ToDo Liste stand die Erweiterung auf n x FIELD womit sich das Problem erledigt haben sollte in Version 10 ... oder 11.

wer eine v10 oder v11 installiert hat bitte mal nachsehen unter "CREATE INDEX" ob man inzwischen n x FIELD verwenden kann.

---

ich habe bei PGU den Header als Auswahl für ORDER BY mit der linken Maus-Taste
das "umschalten" bei 500000 Sätzen auf eine TEXT Column dauert einige Sekunden ohne "echten" PostgreSQL Index.

mit der rechten Maus-Taste erzeuge ich nun einen PostgreSQL Index.
danach dauert das "umschalten" 2/100 Sek. :!:

mal ein Logfile meiner Table
Table have 551403 entry

// Index anlegen
SELECT ...
CREATE INDEX Index_fartikel ON fsicher (fartikel)
Erfolgreicher Abschluss eines Befehls, der keine Daten liefert. 4.48
Sec.

SELECT ...
change to ORDER BY fanzahl Time 1.54 Sec.
CREATE INDEX Index_fanzahl ON fsicher (fanzahl)
Erfolgreicher Abschluss eines Befehls, der keine Daten liefert. 1.78
Sec.

SELECT ...
change to ORDER BY fartnr Time 5.03 Sec.
CREATE INDEX Index_fartnr ON fsicher (fartnr)
Erfolgreicher Abschluss eines Befehls, der keine Daten liefert. 2.59
Sec.

// jetzt mit Index

SELECT ...
change to ORDER BY fartikel Time 0.02 Sec.

SELECT ...
change to ORDER BY fartnr Time 0.02 Sec.
search fartnr for WHERE fartnr >= '4001' Order fartnr
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Hallo, Carlo.

Ich weiß nicht, was Du da machst, wenn Du eine Bestellung speicherst, aber es wird schon einiges sein, wenn es mit der ISAM-Emulation eine Minute dauert. Mehrere hundert aufeinanderfolgende Replaces in derselben Tabelle sind natürlich suboptimal. Da muss man der Emulation etwas nachhelfen.

Wir haben hunderte von Anwendungsszenarien, wir haben Einzelplatzkunden und Einrichtungen mit hunderten Arbeitsplätzen, wir haben einigen ADS verkauft und anderen nicht. Wir haben einen Support, der sich mit diversen Topologien auseinandersetzen muss. Und wir möchten nichts als Zwangsupgrade herausgeben, das erstens nicht alle wollen und das sich zweitens (an andere) auch verkaufen lässt. Anders gesagt: Wir können nicht einfach alles andere rausschmeißen und nur noch PG machen, jedenfalls nicht kurzfristig. Aber es ist auch nicht so ein Riesending, den Code für drei Engines parallel zu pflegen.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

sagt mal : wie gross ist die libpqEX.dll die es in Xbase++ v2.x gibt :?: ca. 69 KB :?:

hat jemand schon mal versucht aus der v9.x die libpq.dll umbenannt in libpqEX.dll und die zusammen mit
04.03.2016 14:39 1.206.784 libeay32.dll
29.03.2016 05:59 67.072 libecpg.dll
29.03.2016 05:59 15.360 libecpg_compat.dll
09.07.2015 12:58 1.015.942 libiconv-2.dll
10.07.2015 11:30 1.542.289 libintl-8.dll
29.03.2016 05:59 64.000 libpgtypes.dll
29.03.2016 05:59 144.896 libpq.dll
02.07.2015 13:44 1.767.424 libxml2.dll
02.07.2015 14:02 311.296 libxslt.dll
04.03.2016 14:39 272.896 ssleay32.dll
03.07.2015 13:39 68.608 zlib1.dll
zu verwenden :-"
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Jimmy,

201 KB, Version 8.3.1.8104

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Jan hat geschrieben: Mi, 03. Jul 2019 10:01 201 KB, Version 8.3.1.8104
OK , dann ist da noch "mehr" drin ... vermutlich der Xbase++ "Wrapper" mit den DLLFUNCTION
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Tom
Ich weiß nicht, was Du da machst, wenn Du eine Bestellung speicherst, aber es wird schon einiges sein, wenn es mit der ISAM-Emulation eine Minute dauert. Mehrere hundert aufeinanderfolgende Replaces in derselben Tabelle sind natürlich suboptimal. Da muss man der Emulation etwas nachhelfen.
Eigentlich ganz einfach: in einer schlaufe, append blank, felder füllen usw. usw.

Wie sind denn deine Erfahrungen mit der ISAM-EMU? Ich kann mir das nicht vorstellen dass es bei dir so sorglos läuft.

Ja, mit hunderten Anwendern ist es sicher schwieriger die DBE zu wechseln, aber auch nicht unmöglich. Ich würde es dennoch tun.
Valar Morghulis

Gruss Carlo
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Jimmy
hat jemand schon mal versucht aus der v9.x die libpq.dll umbenannt in libpqEX.dll und die zusammen mit
das würde ich niemals tun. DIe PGDBE baut ja darauf auf, könnte die so einfach gewechselt werden hätte Alaska das sicherlich gemacht.

Aktuell ist:

libpq.dll 18.06.2019 Version 11.0.3.19168 240'640 Bytes
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Tom hat geschrieben: Mi, 03. Jul 2019 9:05 Wir können nicht einfach alles andere rausschmeißen und nur noch PG machen, jedenfalls nicht kurzfristig. Aber es ist auch nicht so ein Riesending, den Code für drei Engines parallel zu pflegen.
auch beim ADS Server ist ja ein Ende abzusehen also muss man sich nach einem anderen Server umsehen wobei SQL angesagt wäre.

die API zu libpq.dll enthält ja nicht viele Function die nur für die "Kommunikation" mit dem PostgreSQL Server sind.
es ist die Qwery welche die Arbeit macht aber die wird dann auf allen Plattformen laufen.

---
Tom hat geschrieben: Man kann z.B. den InString-Operator ($) im Moment mit der PGDBE nicht in Filterausdrücken verwenden
hm ... es gab unter v8.x doch schon LIKE was mir die selben Resultate liefert wie $
Frage : SET OPTIMIZE OFF :?:
Tom hat geschrieben:und die Sache mit dem DELETED ON und Standard-Navigationscodeblöcken im XbpBrowse ist auch noch nicht geklärt.
es gibt ja das interne FIELD "__deleted" was für die Query verwendet werden kann.

DbPosition() wäre in der PostgreSQL v9.x Version kein Problem mit der Function row_number() in einer Query

XbpBrowse() mit Array ist OK aber mit der PgDBE Emulation wie eine DBF [-X

---

Frage : wie sieht es aus mit DataObject und Browse :?:

das komplette Result-Set kann man sich doch als DataObject zurück geben lassen, oder :?:
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Jimmy, liest Du nicht, was ich schreibe? Klar kann ich ein LIKE in SQL verwenden, oder tausend andere Sachen, aber wenn ich denselben Code für drei Engines verwenden will, dann sind Workarounds eben nur fallweise sinnvoll. Deshalb habe ich vieles so umgebaut (ganz abgeschlossen ist das noch nicht), dass es in allen drei Fällen gut funktioniert.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Jimmy,

Du warst doch auf dem letzten Forentreffen dabei, oder? Da hatte ich erzählt, das man per SELCT die Daten in ein DO holen kann.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Was mit allen Engines funktioniert.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Tom,

exakt. SELECT geht immer, egal ob auf SQL oder dbf oder sonstwas. OK, bei "sonstwas" bin ich mir gerade nicht ganz sicher, DELDBE und SDFDBE sind ja manchmal etwas anders als dbf.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Tom hat geschrieben: Mi, 03. Jul 2019 11:28 Jimmy, liest Du nicht, was ich schreibe?
wie ich schrieb
es ist die Qwery welche die Arbeit macht aber die wird dann auf allen Plattformen laufen.
wie dann die Eingabe-/Ausgabe- auf verschiedenen Geräten / Plattformen ausfällt ist eine andere Sache.

Tom hat geschrieben: Klar kann ich ein LIKE in SQL verwenden, oder tausend andere Sachen, aber wenn ich denselben Code für drei Engines verwenden will, dann sind Workarounds eben nur fallweise sinnvol
ich kam auf LIKE weil du

Code: Alles auswählen

Begriff § String
angesprochen hattest.
klar weiss ich nicht was Alaska in der PgDBE ISAM Emulation daraus macht ... und ob OPTIMIZE bei der PgDBE was ausmacht

nun ist das aber genau der Punkt den Ich meine das die erarbeitet Query für alle Sprachen / Plattform gleich ist weil es an den SQL Server geht. die Query ist ja in PostgreSQL Syntax welche durch die ISAM Emulation "übersetzt" wird ... so wie es Alaska meint.

--- Anmerkung ---
wenn man ein Query im PgAdmin mit F7 abschickt werden einem die "Kosten" angezeigt.
per ANALYZE kann man dann raus finden ob es "preiswerter" geht -> bessere Performance

mit der ISAM Emulation hat man keine Chance der Optimierung der Query und ggf der zugehörigen Index Dateien
--- eof ---

aber egal von welcher Engine nun das Resultat kommt ... solange das Ergebnis das selbe ist.
dann geht es nur noch um das "Ausgabe" Format. wenn nun das Ergebnis als Array vorliegt könnten andere Sprachen / Plattform die Daten übernehmen.

---

ich weiss wie "gross" eine Xbase++ App werden kann und das Erweitern oder Umschreiben für eine andere Sprache erscheint kaum möglich.

wenn man ein neue Project heute anfängt kann man auf viele "ISAM Altlasten" verzichten weil man die unter SQL nicht benötigt.

meine Frage in diesem Thread was ja auch : "was" von der ISAM Emulation braucht man wirklich "wofür" :?:

man kann doch mit der PgDBE "direkt" arbeiten ohne die ISAM Emulation, oder :?:
gruss by OHR
Jimmy
Antworten