PGDBE + ISAM [erledigt]
Moderator: Moderatoren
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
PGDBE + ISAM [erledigt]
Hallo
Hab ich das richtig installiert:
Nach einem Upsize hab ich die Felder in den _order_? gefüllt.
Ein UPDATE oder INSERT durch SQL pflegt diese Felder nicht. Es gibt keine Trigger dazu. Die Logik ist wohl in der PGDBE.
Hab Postgres 11 im Einsatz. Liegts vieleicht daran?
Oder ?
Hab ich das richtig installiert:
Nach einem Upsize hab ich die Felder in den _order_? gefüllt.
Ein UPDATE oder INSERT durch SQL pflegt diese Felder nicht. Es gibt keine Trigger dazu. Die Logik ist wohl in der PGDBE.
Hab Postgres 11 im Einsatz. Liegts vieleicht daran?
Oder ?
Zuletzt geändert von Marcus Herz am Do, 30. Jan 2020 11:10, insgesamt 1-mal geändert.
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: PGDBE + ISAM
Servus Markus,
ich arbeite zwar nicht mit ISAM, sondern ausschließlich mit Pass-Through, aber bei ISAM musst eigentlich nichts beachten, auch keine _order_-Felder selber füllen. Alaska legt da die Trigger alle selber an und das passt so auch. Sogar bei reinem Pass-Through werden die angelegt, sowie auch die 3 Alaska-Tabellen für jede DB, dafür sorgt die PGDBE.
PG11 funktioniert einwandfrei, nur die 12er hat ein Problem, siehe PDR 7254.
ich arbeite zwar nicht mit ISAM, sondern ausschließlich mit Pass-Through, aber bei ISAM musst eigentlich nichts beachten, auch keine _order_-Felder selber füllen. Alaska legt da die Trigger alle selber an und das passt so auch. Sogar bei reinem Pass-Through werden die angelegt, sowie auch die 3 Alaska-Tabellen für jede DB, dafür sorgt die PGDBE.
PG11 funktioniert einwandfrei, nur die 12er hat ein Problem, siehe PDR 7254.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM
Das gilt nur, wenn du ausschließlich mit der PGDBE arbeitest, auch das pass-through. Nicht wenn du mit PgAdmin etwas korrigierst !!!
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: PGDBE + ISAM
Erwartest Du was anderes?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM
Ja.
Da ist die PGDBE ja schon eine Sackgasse. Schliesst ja jedes ander Tool, z.B. Web Anwendung, aus.
Ich hab jetzt halt Trigger für das Update der _order Felder definiert.
Da ist die PGDBE ja schon eine Sackgasse. Schliesst ja jedes ander Tool, z.B. Web Anwendung, aus.
Ich hab jetzt halt Trigger für das Update der _order Felder definiert.
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9387
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 103 Mal
- Danksagung erhalten: 362 Mal
- Kontaktdaten:
Re: PGDBE + ISAM
Nein, die PGDBE ist keine Sackgasse. Man muss nur daran denken, dass die damit verbundene Systematik vor allem dem Zweck dient, ISAM zu simulieren. Dafür sind einige Bedingungen zu erfüllen und Regeln einzuhalten, und dazu gehört, dass man die PGDBE zu nutzen versucht, wenn es zu Service- und Wartungsfragen kommt. Solche Tools wie VDBU und XDBU und hauseigene (von denen wir eine ganze Menge haben) können mit wenigen Anpassungen für die Datenbankwartung verwendet werden. Abfragen sind natürlich möglich, aber man sollte Tabellen und Datenbanken, die per PGDBE verwendet werden, gefälligst auch nur über die DBE aktualisieren, warten und sonstwie bearbeiten.
Herzlich,
Tom
Tom
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Laut Alaska ist eine XBASE Runtime zuständig für die Pflege der _order Dateien.
Sprich: die Client Anwendung ist für die Integrität der Datenbank zuständig.
Davon wollten wir doch weg. Das ist keine Client-Server Architektur
Sprich: die Client Anwendung ist für die Integrität der Datenbank zuständig.
Davon wollten wir doch weg. Das ist keine Client-Server Architektur
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: PGDBE + ISAM [erledigt]
Servus Marcus,
wie sollte das auch gehen bei ISAM? Dann mach pass-through und Du hast Deine Client-Server Version im Xbase++ - Syntax.
wie sollte das auch gehen bei ISAM? Dann mach pass-through und Du hast Deine Client-Server Version im Xbase++ - Syntax.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: PGDBE + ISAM [erledigt]
Gibt es trotzdem eine Möglichkeit die ISAM-Tabellen zu aktualisieren, nachdem man mit einem SQL Statement außerhalb der PGDBE Daten aktualisiert hat? Wir haben nämlich immer wieder hybride Anwendungen, die teilweise in anderen Programmiersprachen geschrieben wurden. Über Sinn und Unsinn will ich an der Stelle gar nicht diskutieren. Wenn man beispielsweise mit C# einen Datensatz aus einer mit ISAM erstellten Tabelle per UPDATE ändert, dann werden dadurch (logischerweise) die von Alaska verwalteten ISAM-Simulations-Indizes nicht mit geändert. Kann man das irgendwie noch anstoßen von außen?
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hallo
Ich habe Trigger für die Pflege der __order Felder geschrieben. Damit ist das save auch für andere Programme, die da reinschreiben
Ich habe Trigger für die Pflege der __order Felder geschrieben. Damit ist das save auch für andere Programme, die da reinschreiben
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Frank Grossheinrich
- Rekursionen-Architekt
- Beiträge: 147
- Registriert: Fr, 31. Mär 2017 15:06
- Wohnort: Eschborn
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 82 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Benz,
Gruß, Frank
Man muss nichts von "außen" anstoßen. Das geht implizit. Die PGDBE merkt, wenn Schlüsselfelder verändert wurden.Wenn man beispielsweise mit C# einen Datensatz aus einer mit ISAM erstellten Tabelle per UPDATE ändert, dann werden dadurch (logischerweise) die von Alaska verwalteten ISAM-Simulations-Indizes nicht mit geändert. Kann man das irgendwie noch anstoßen von außen?
Gruß, Frank
We love Xbase++, and you?
- Manfred
- Foren-Administrator
- Beiträge: 21211
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: PGDBE + ISAM [erledigt]
wir reden doch aber jetzt nur davon, wenn man die Postgres über euer upsize Tool nutzt und weiterhin die xbase++ Befehle benutzen will? Oder gilt das generell auch für reines SQL auf die Postgres?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hi Frank
Ich hatte im Februar auch deswegen Kontakt mit eurem Support. Die Aussage damals:
Werden Schlüsselfelder von außen verändert muss man reinidzieren.
Nur für mein Verständnis: die PGDBE merkt das wenn der Satz gelesen wird, oder gibt es da noch eineen anderen Mechanismus?
Ich hatte im Februar auch deswegen Kontakt mit eurem Support. Die Aussage damals:
Werden Schlüsselfelder von außen verändert muss man reinidzieren.
Nur für mein Verständnis: die PGDBE merkt das wenn der Satz gelesen wird, oder gibt es da noch eineen anderen Mechanismus?
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Frank Grossheinrich
- Rekursionen-Architekt
- Beiträge: 147
- Registriert: Fr, 31. Mär 2017 15:06
- Wohnort: Eschborn
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 82 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hey Manfred,
jetzt verstehe *ich* *dich* nicht mehr
Benz sprach doch von ISAM Tabelle. Und darauf habe ich geantwortet.
Ehmm, versucht zu antworten.
Und?
Gruß, Frank
jetzt verstehe *ich* *dich* nicht mehr
Benz sprach doch von ISAM Tabelle. Und darauf habe ich geantwortet.
Ehmm, versucht zu antworten.
Und?
Gruß, Frank
We love Xbase++, and you?
- Manfred
- Foren-Administrator
- Beiträge: 21211
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: PGDBE + ISAM [erledigt]
Hi Frank,
kein Problem, ich verstehe im Moment auch nichts mehr. Ich glaube ich mache jetzt Feierabend, oder haue ein paar Nägel in eine Betonwand.
kein Problem, ich verstehe im Moment auch nichts mehr. Ich glaube ich mache jetzt Feierabend, oder haue ein paar Nägel in eine Betonwand.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Frank Grossheinrich
- Rekursionen-Architekt
- Beiträge: 147
- Registriert: Fr, 31. Mär 2017 15:06
- Wohnort: Eschborn
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 82 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Marcus,
Du hast eine Datenbank, die mit dem Upsize Tool von DBF nach Postgres migriert wurde.
Alles funktioniert so weit.
Nun gehst du mit was auch immer daher und veränderst von einer Tabelle - sagen wir mal Kunden - den Namen eines Kunden per SQL und auf dieses Feld der Kundentabelle gibt es einen Index. Die Xbase++ Anwendung/PGDBE wird merken, dass du "von extern" diesen Record und das Schlüsselfeld geändert hast. Das ist ein Zusammenspiel der Spalten _rowversion und _keyversion. Der nächste PGDBE Lesezugriff wird die korrekte Information haben!
1) index-key-value is stored at an index-key-column at row level.
2) Update via SQL lead to a _rowversion increment due to trigger but no _keyversion increment.
3) PGDBE can with next ISAM access identify inconsistency and "fix" invalid key value
4) see also https://doc.alaska-software.com/content ... erver.html (under construction)
Nochmals: was hast du gemacht und was hat dann nicht geklappt?
Gruß, Frank
Wenn das unser Support gesagt hat, dann wäre das falsch. Ich bezweifle das aber (hoffentlich).Werden Schlüsselfelder von außen verändert muss man reinidzieren.
Ich weiß leider nicht, was du EXAKT meinst.Nur für mein Verständnis: die PGDBE merkt das wenn der Satz gelesen wird, oder gibt es da noch eineen anderen Mechanismus?
Du hast eine Datenbank, die mit dem Upsize Tool von DBF nach Postgres migriert wurde.
Alles funktioniert so weit.
Nun gehst du mit was auch immer daher und veränderst von einer Tabelle - sagen wir mal Kunden - den Namen eines Kunden per SQL und auf dieses Feld der Kundentabelle gibt es einen Index. Die Xbase++ Anwendung/PGDBE wird merken, dass du "von extern" diesen Record und das Schlüsselfeld geändert hast. Das ist ein Zusammenspiel der Spalten _rowversion und _keyversion. Der nächste PGDBE Lesezugriff wird die korrekte Information haben!
1) index-key-value is stored at an index-key-column at row level.
2) Update via SQL lead to a _rowversion increment due to trigger but no _keyversion increment.
3) PGDBE can with next ISAM access identify inconsistency and "fix" invalid key value
4) see also https://doc.alaska-software.com/content ... erver.html (under construction)
Nochmals: was hast du gemacht und was hat dann nicht geklappt?
Gruß, Frank
We love Xbase++, and you?
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hi Frank
Das war die Antwort: der nächste Lesezugriff merkt das. Dann ist das für mich verständlich und neu.
Rückblick: Der Hinweis auf Reindex vom Support war insofern richtig, weil wir über SQL Bulk Import jede Menge Daten in der DBMS erzeugt haben. Und da hat ja logischerweise der Inhalt der __order Felder gefehlt. Und durch die Tabellen zu skippen, um jeden Satz zu aktualisieren, war da keine Option.
Das war die Antwort: der nächste Lesezugriff merkt das. Dann ist das für mich verständlich und neu.
Rückblick: Der Hinweis auf Reindex vom Support war insofern richtig, weil wir über SQL Bulk Import jede Menge Daten in der DBMS erzeugt haben. Und da hat ja logischerweise der Inhalt der __order Felder gefehlt. Und durch die Tabellen zu skippen, um jeden Satz zu aktualisieren, war da keine Option.
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- Manfred
- Foren-Administrator
- Beiträge: 21211
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: PGDBE + ISAM [erledigt]
OK,
ich glaube ich bin jetzt auch wieder dabei. Hier geht es um den Upsize Vorgang. Darauf bezog sich alles.
ich glaube ich bin jetzt auch wieder dabei. Hier geht es um den Upsize Vorgang. Darauf bezog sich alles.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Frank Grossheinrich
- Rekursionen-Architekt
- Beiträge: 147
- Registriert: Fr, 31. Mär 2017 15:06
- Wohnort: Eschborn
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 82 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hi Marcus,
ich verstehe deine Anforderung immer noch nicht!
Du, als Entwickler, hast die Finger von den Meta Daten der PGDBE zu lassen. Die gehören der Alaska Software. Wer das durcheinander bringt, der macht zerstörte Daten.
Du kannst Bulk-mäßig so viel in die Tabellen klopfen, wie du möchtest. Kümmere dich nicht um die Meta-Informationen.
Diese verwalten sich selbst.
Du kannst NATÜRLICH NICHT Daten per SQL INSERTen und erwarten, dass sich dann die Meta-Informationen (die alleine für Xbase++ relevant sind) von alleine füllen/ändern, damit sie wieder in SQL verfügbar sind. Wer oder was verlässt sich denn auf diese Meta-Daten außer Xbase++? Aber die Xbase++ Anwendung wird IMMER die richtigen Daten sehen und das ist doch das EINZIG Wichtige.
Ansonsten musst du mir dann doch den Sinn und dein Vorhaben erklären (bitte dann etwas genauer).
Die wichtige Botschaft: egal, was ich von außen ändere, PGDBE wird immer korrekt suchen, anzeigen, ...
Und nur zum besseren Verständnis:
DBMS ist nicht gleich eine Datenbank! Du meintest aber einen Datenbank, oder?
Gruß, Frank
ich verstehe deine Anforderung immer noch nicht!
Du, als Entwickler, hast die Finger von den Meta Daten der PGDBE zu lassen. Die gehören der Alaska Software. Wer das durcheinander bringt, der macht zerstörte Daten.
Du kannst Bulk-mäßig so viel in die Tabellen klopfen, wie du möchtest. Kümmere dich nicht um die Meta-Informationen.
Diese verwalten sich selbst.
Du kannst NATÜRLICH NICHT Daten per SQL INSERTen und erwarten, dass sich dann die Meta-Informationen (die alleine für Xbase++ relevant sind) von alleine füllen/ändern, damit sie wieder in SQL verfügbar sind. Wer oder was verlässt sich denn auf diese Meta-Daten außer Xbase++? Aber die Xbase++ Anwendung wird IMMER die richtigen Daten sehen und das ist doch das EINZIG Wichtige.
Ansonsten musst du mir dann doch den Sinn und dein Vorhaben erklären (bitte dann etwas genauer).
Die wichtige Botschaft: egal, was ich von außen ändere, PGDBE wird immer korrekt suchen, anzeigen, ...
Und nur zum besseren Verständnis:
DBMS ist nicht gleich eine Datenbank! Du meintest aber einen Datenbank, oder?
Gruß, Frank
We love Xbase++, and you?
- Marcus Herz
- 1000 working lines a day
- Beiträge: 858
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 192 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Hi Frank
Alles gut. Wir hatten mit Upsize die leeren Tabellen (viele = Datenbank, nicht DBMS, du hast recht) erzeugt und mittels SQL die Daten gefüllt. Es ging dabei um ca. 1,3 GB Daten. Weil das Upsize da doch etwas langsam war, haben wir eben einem Postgres Import ausgeführt. Und dann mussten wir halt reindizieren
Alles gut. Wir hatten mit Upsize die leeren Tabellen (viele = Datenbank, nicht DBMS, du hast recht) erzeugt und mittels SQL die Daten gefüllt. Es ging dabei um ca. 1,3 GB Daten. Weil das Upsize da doch etwas langsam war, haben wir eben einem Postgres Import ausgeführt. Und dann mussten wir halt reindizieren
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- AUGE_OHR
- Marvin
- Beiträge: 12911
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE + ISAM [erledigt]
hi Frank,
die 3 Table sind doch "eingebaut" als
und die beiden Trigger
was aber NICHT dokumentiert ist wonach Benz fragt.
Das Alaska "meint" das die PostgreSQL nur von Xbase++ "genutzt" werden können ist natürlich nicht Sinn der Sache
eine externe App welche auf eine PostgreSQL Table zugreift benötigt nicht die "zusätzlichen" Felder für den INDEXKEY() Ausdruck sondern greift nur auf das FIELD zu um es evtl. zu verändern.Benz hat geschrieben: ↑Di, 28. Apr 2020 14:21 Wenn man beispielsweise mit C# einen Datensatz aus einer mit ISAM erstellten Tabelle per UPDATE ändert, dann werden dadurch (logischerweise) die von Alaska verwalteten ISAM-Simulations-Indizes nicht mit geändert. Kann man das irgendwie noch anstoßen von außen?
die 3 Table sind doch "eingebaut" als
Code: Alles auswählen
"alaska-software.isam.tables"
"alaska-software.system.connections"
"alaska-software.isam.orders"
Code: Alles auswählen
"isam_rowversion_update"
"isam_tablemeta_update"
Das Alaska "meint" das die PostgreSQL nur von Xbase++ "genutzt" werden können ist natürlich nicht Sinn der Sache
gruss by OHR
Jimmy
Jimmy
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: PGDBE + ISAM [erledigt]
Ich habe jetzt per C# über INSERT mit NPGSQL in eine Tabelle geschrieben, die von Xbase++ ISAM verwaltet wird.
Anschließend habe ich mit meinem Xbase Programm, welches ganz normal SEEK benutzt, versucht auf die neuen Daten zuzugreifen, leider ohne Erfolg. Der Zugriff erfolgt mit Einsatz eines Index.
Also habe ich in der Postgre-Datenbank nachgeschaut und der Eintrag mit INSERT existiert dort, die Spalten, die die PGDBE füllen sollte, sind allerdings leer (s. Screenshot).
Die unteren beiden Datensätze habe ich per C#-INSERT hinzugefügt, die darüber alle mit Xbase++/ISAM/PGDBE.
Reicht ein SEEK also nicht aus um die Indices zu reindizieren für neue Datensätze?
Die Gegenprobe mit einem Datensatz, der von Xbase++/ISAM/PGDBE erzeugt wurde hat funktioniert, hier konnte ich auf den Datensatz per SEEK zugreifen
Anschließend habe ich mit meinem Xbase Programm, welches ganz normal SEEK benutzt, versucht auf die neuen Daten zuzugreifen, leider ohne Erfolg. Der Zugriff erfolgt mit Einsatz eines Index.
Code: Alles auswählen
SEEK str(val(memmitarbeiternummer),6,0)+dtos(ctod(memdatum))+str(auhrbis[memanzahl],5,2)
Die unteren beiden Datensätze habe ich per C#-INSERT hinzugefügt, die darüber alle mit Xbase++/ISAM/PGDBE.
Reicht ein SEEK also nicht aus um die Indices zu reindizieren für neue Datensätze?
Die Gegenprobe mit einem Datensatz, der von Xbase++/ISAM/PGDBE erzeugt wurde hat funktioniert, hier konnte ich auf den Datensatz per SEEK zugreifen
- Dateianhänge
-
- a.PNG (131.79 KiB) 12810 mal betrachtet
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: PGDBE + ISAM [erledigt]
Ein SEEK wird nie einen Reindex ausführen, das wäre zeitlich gar nicht möglich.
Ich ging daher davon aus, dass Alaska trigger eingebaut hat, mit deren Hilfe bei Änderung relevanter Felder auch das Indexfeld erstellt wird.
Frank++ hatte aber vor kurzem erklärt (Frank Grossheinrich » Di, 28. Apr 2020 15:49 etwas weiter oben hier), dass die PQDBE beim nächsten Einlesen des Datensatzes die Infos nachpflegt.
Somit müsste wohl oder übel nach jedem externen Zugriff ein dbeval() durchlaufen, das die Feldinfos ausliest ... probiert habe ich es nicht, denn ich nutze die PGDBE nicht.
Wenn ich mal einen SQL Server Zugriff brauche, nehme ich meine altgediente SQLexpress() Version.
Ich ging daher davon aus, dass Alaska trigger eingebaut hat, mit deren Hilfe bei Änderung relevanter Felder auch das Indexfeld erstellt wird.
Frank++ hatte aber vor kurzem erklärt (Frank Grossheinrich » Di, 28. Apr 2020 15:49 etwas weiter oben hier), dass die PQDBE beim nächsten Einlesen des Datensatzes die Infos nachpflegt.
Somit müsste wohl oder übel nach jedem externen Zugriff ein dbeval() durchlaufen, das die Feldinfos ausliest ... probiert habe ich es nicht, denn ich nutze die PGDBE nicht.
Wenn ich mal einen SQL Server Zugriff brauche, nehme ich meine altgediente SQLexpress() Version.
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: PGDBE + ISAM [erledigt]
hm ok, ich hätte gedacht, dass das SEEK auch einen Trigger auslöst, aber das gehört dann wohl nicht zu den Dingen, die einen ISAM-Zugriff machen.
Also doch im ganzen Programm ein DBEval überall bei SEEK einbauen
Na wenn das mal nicht ordentlich an der Performance kratzt
Also doch im ganzen Programm ein DBEval überall bei SEEK einbauen
Na wenn das mal nicht ordentlich an der Performance kratzt
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: PGDBE + ISAM [erledigt]
Entweder mache ich was falsch oder mit DBEval geht es auch nicht.
Das hier müsste doch eigentlich reichen oder?
Das hier müsste doch eigentlich reichen oder?
Code: Alles auswählen
USE PERSZEIT
DbEval( {|| msgbox("ABC") } )