PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Wir kommen auch mit den Servicefunktionen allmählich auf die Zielgerade, aber ich hadere noch mit den Optionen, die es bei notwendigen Strukturänderungen gibt. Im klassischen dateibasierten Konzept erzeugt man eine Tabelle mit der neuen, geänderten Struktur, holt die Datensätze per APPEND, löscht die alte Tabelle und benennt die neue anschließend um. Die ersten beiden Schritte sind ohne Änderungen auch mit der PGDBE möglich. Damit die Metadaten konsistent bleiben und auch sonst nichts bricht, würde ich ungerne mit ALTER TABLE und DROP TABLE hantieren. Aber ich finde auch in den Docs leider nichts zu diesem Thema. Hat jemand einen Ansatz?
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi
ich habe keine Erfahrung mit der ISAM-Emulation aber "normal" muss man kein
ausführen um die Structure zu ändern
ich habe keine Erfahrung mit der ISAM-Emulation aber "normal" muss man kein
Code: Alles auswählen
DROP TABLE
Code: Alles auswählen
METHOD ModiDialog:MySaveDel( oDraw, cTable, aStruct, aInStruct, oPG, lNew, aWorkStru )
...
cQuery := "ALTER TABLE " + cTable + " DROP COLUMN " + cFeld
Code: Alles auswählen
METHOD ModiDialog:MySaveNew( oDraw, cTable, aStruct, aInStruct, oPG, lNew, aWorkStru )
...
IF lNew
cQuery += "CREATE TABLE " + cTable + " ( "
ELSE
cQuery += "ALTER TABLE " + cTable + " ADD COLUMN "
ENDIF
...
IF lNew
//
// from "id" change to "__record"
//
// add "internal" Fields
//
cQuery += " __deleted boolean NOT NULL DEFAULT false, "
cQuery += " __record serial NOT NULL, "
cQuery += " __rowversion integer NOT NULL DEFAULT 0, "
cQuery += " __keyversion integer NOT NULL DEFAULT 0, "
cQuery += " __lock_owner integer NOT NULL DEFAULT 0, "
// Alaska have this
//
// CONSTRAINT artikel_pkey PRIMARY KEY (__record)
//
cQuery += " CONSTRAINT " + cTable + "_pkey PRIMARY KEY (__record)"
cQuery += " )" // NEED
ELSE
cQuery := SUBSTR( cQuery, 1, LEN( cQuery ) - 2 )
ENDIF
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Hallo, Jimmy.
Ich weiß, dass man ALTER TABLE ohne DROP TABLE nutzen kann, und ich weiß auch, wie ich in direkter Kommunikation mit einem beliebigen SQL-Server Tabellenstrukturen ändern kann, aber ES GEHT UM DIE PGDBE. Und damit um etwas mehr als nur ALTER TABLE. Etwas sehr viel mehr. Deshalb sind Deine Anmerkungen leider nicht sehr hilfreich. Man muss in der Navigationssyntax bleiben, damit die Tabellen und Indexe und Inhalte erhalten bleiben, damit die Metadaten aktuell sind, die Counter und Indexe und Pseudoindexe und Trigger und was weiß ich noch alles perfekt sitzen. Es geht nicht nur darum, die Struktur einer Tabelle zu ändern. Und auch mit der Ergänzung der internen Felder ist es nicht getan.
Ich weiß, dass man ALTER TABLE ohne DROP TABLE nutzen kann, und ich weiß auch, wie ich in direkter Kommunikation mit einem beliebigen SQL-Server Tabellenstrukturen ändern kann, aber ES GEHT UM DIE PGDBE. Und damit um etwas mehr als nur ALTER TABLE. Etwas sehr viel mehr. Deshalb sind Deine Anmerkungen leider nicht sehr hilfreich. Man muss in der Navigationssyntax bleiben, damit die Tabellen und Indexe und Inhalte erhalten bleiben, damit die Metadaten aktuell sind, die Counter und Indexe und Pseudoindexe und Trigger und was weiß ich noch alles perfekt sitzen. Es geht nicht nur darum, die Struktur einer Tabelle zu ändern. Und auch mit der Ergänzung der internen Felder ist es nicht getan.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi,
wenn ich ein neues FIELD anfüge gibt es kein "internes Index FIELD" (es sei denn ich definieren einen neuen Index)
aber du hast Recht das noch was fehlt
der PRIMARY KEY wird durch nextval() auf den aktuellen Stand gebracht.
wenn ich ein neues FIELD anfüge gibt es kein "internes Index FIELD" (es sei denn ich definieren einen neuen Index)
aber du hast Recht das noch was fehlt
Code: Alles auswählen
// letzte Zeile vorheriger Code
oPG:exec( cQuery )
// das kommt "danach"
IF ResultStatus( oPG, oMain )
IF lNew
cIns := cPreText
i := 1
FOR i = 1 TO LEN( aWorkStru )
DO CASE
CASE aWorkStru[ i, 2 ] = "C"
cIns += " '" + STRTRAN( SPACE( aWorkStru[ i, 3 ] ), "'", '"' ) + "',"
CASE aWorkStru[ i, 2 ] = 'N'
cIns += " " + ALLTRIM( STR( 0, aWorkStru[ i, 3 ], aWorkStru[ i, 4 ] ) ) + ","
CASE aWorkStru[ i, 2 ] = 'D'
cIns += " '" + DE_SQLdate( DATE() ) + "',"
CASE aWorkStru[ i, 2 ] = 'M'
cIns += " '" + STRTRAN( "hello world", "'", '"' ) + "',"
CASE aWorkStru[ i, 2 ] = "L"
cIns += " " + "false, "
CASE aWorkStru[ i, 2 ] = "B"
cIns += " '" + STRTRAN( SPACE( aWorkStru[ i, 3 ] ), "'", '"' ) + "',"
ENDCASE
NEXT
// add "__deleted" default
//
cIns += "false," // "__deleted"
// nextval() for Sequence !
//
cIns += "nextval('" + cTable + "___record_seq')" + "," // use nextval()
cIns += "0," // "__rowversion"
cIns += "0," // "__keyversion"
cIns += "0 " // "__lock_owner"
cIns += ")"
cIns := STRTRAN( cIns, CHR( 0 ), " " ) // if any CHR(0)
oPG:exec( cIns ) //
IF ResultStatus( oPG, oMain ) // now get Result Status
cQuery := "CREATE TRIGGER " + cTable + "_isam_rowversion AFTER UPDATE ON " + ;
cTable + " FOR EACH ROW EXECUTE PROCEDURE isam_rowversion_update()"
oPG:exec( cQuery )
IF ResultStatus( oPG, oMain )
cQuery := "CREATE TRIGGER " + cTable + "_isam_tablemeta AFTER INSERT OR UPDATE OR DELETE ON " + ;
cTable + " FOR EACH ROW EXECUTE PROCEDURE isam_tablemeta_update()"
oPG:exec( cQuery )
IF ResultStatus( oPG, oMain )
oMain:oListTable:addItem( cTable )
ENDIF
ENDIF
ENDIF
ENDIF
ELSE
oMain:OutMsg( "Query :" + cQuery + " fail" )
ENDIF
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Wo kommt das her, Jimmy?
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi Tom,
mit ist durchaus bewusst was PgDBE macht und wozu die "internen" FIELD(s) sind.
du spricht nun von "modifizieren" der PG-Table und da braucht man kein
probieren es doch einfach mal mit PgAdmin
mit ist durchaus bewusst was PgDBE macht und wozu die "internen" FIELD(s) sind.
du spricht nun von "modifizieren" der PG-Table und da braucht man kein
Code: Alles auswählen
DROP TABLE
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2128
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Servus Tom,
wir arbeiten ja bekanntlich nicht im ISAM-Modus wg. der leider immer noch bestehenden Fehler und Einschränkungen, die eine gesamte Überarbeitung unseres Codes nötig machen würde, sondern seit 2016 im produktiven Einsatz bei uns und unseren Kunden mit Pass-Through. Dort nutzen wir seit Anfang an den Alter table - Befehl ohne Probleme. Im ISAM-Modus dürfte das doch auch kein Thema sein, Alaska hat inzwischen ja den konkurrierenden Betrieb ISAM und SQL / Pass-Through "freigegeben"?
Geht ja fast ohne Zeitverzögerung im Gegensatz zu Deiner bisherigen Methode und ich hab jetzt sogar grad mal eine Feldänderung von numeric in character und wieder zurück getestet, funktioniert einwandfrei und rasend schnell! Du kannst Dir das Umschaufeln der Daten sparen. Vor jeder Änderung der Struktur machen wir aber sicherheitshalber eine Sicherung mittels copy to - Befehl.
wir arbeiten ja bekanntlich nicht im ISAM-Modus wg. der leider immer noch bestehenden Fehler und Einschränkungen, die eine gesamte Überarbeitung unseres Codes nötig machen würde, sondern seit 2016 im produktiven Einsatz bei uns und unseren Kunden mit Pass-Through. Dort nutzen wir seit Anfang an den Alter table - Befehl ohne Probleme. Im ISAM-Modus dürfte das doch auch kein Thema sein, Alaska hat inzwischen ja den konkurrierenden Betrieb ISAM und SQL / Pass-Through "freigegeben"?
Geht ja fast ohne Zeitverzögerung im Gegensatz zu Deiner bisherigen Methode und ich hab jetzt sogar grad mal eine Feldänderung von numeric in character und wieder zurück getestet, funktioniert einwandfrei und rasend schnell! Du kannst Dir das Umschaufeln der Daten sparen. Vor jeder Änderung der Struktur machen wir aber sicherheitshalber eine Sicherung mittels copy to - Befehl.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Hallo Tom,
für den Fall, dass man ein neues Feld hinzufügen will (wahrscheinlich die häufigste Änderung), könnte es bald viel einfacher gehen.
Ich habe die gute Nachricht von Alaska bekommen, dass das im folgenden Thread beschildertes Problem im nächsten Update gefixt werden soll:
https://www.xbaseforum.de/viewtopic.php?f=114&t=12053
Wenn dass alles so klappt, dann wird es wenn ich richtig verstehe möglich sein, ein neues Feld einfach mit ALTER TABLE hinzuzufügen, ohne das lästige Auslagern und Wiedereinlesen der Daten.
Natürlich wenn man ein ISAM Index auf dem neuen Feld haben will, erwarte ich dass man dies wie gewohnt über Xbase++ erzeugen muss...
für den Fall, dass man ein neues Feld hinzufügen will (wahrscheinlich die häufigste Änderung), könnte es bald viel einfacher gehen.
Ich habe die gute Nachricht von Alaska bekommen, dass das im folgenden Thread beschildertes Problem im nächsten Update gefixt werden soll:
https://www.xbaseforum.de/viewtopic.php?f=114&t=12053
Wenn dass alles so klappt, dann wird es wenn ich richtig verstehe möglich sein, ein neues Feld einfach mit ALTER TABLE hinzuzufügen, ohne das lästige Auslagern und Wiedereinlesen der Daten.
Natürlich wenn man ein ISAM Index auf dem neuen Feld haben will, erwarte ich dass man dies wie gewohnt über Xbase++ erzeugen muss...
Viele Grüße,
David
David
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi,
wenn du ein FIELD neu "einfügst" in die Postgre Table an welcher Position ist das FIELD ?
wenn das FIELD "angefügt" wird dann ist es "hinter" den "internen" Feldern mit "__"
das ist IHMO ein Problem mit den "internen" Feldern von Akaska
probiere mal ein FIELD aus einer "ISAM" Postgre Table zu löschen ( darf kein Index haben )
ich wette das es klappt genau so wie wenn man ein FIELD "einfügen" würde was vor den "internen" liegt
wenn du ein FIELD neu "einfügst" in die Postgre Table an welcher Position ist das FIELD ?
wenn das FIELD "angefügt" wird dann ist es "hinter" den "internen" Feldern mit "__"
das ist IHMO ein Problem mit den "internen" Feldern von Akaska
probiere mal ein FIELD aus einer "ISAM" Postgre Table zu löschen ( darf kein Index haben )
ich wette das es klappt genau so wie wenn man ein FIELD "einfügen" würde was vor den "internen" liegt
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
@David: Danke für den Hinweis!
@Jimmy: Immer das gleiche Blabla.
@Jimmy: Immer das gleiche Blabla.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi Tom,
VERSUCH macht klug ... und nicht blabla
mit ADD COLUMN an man nur ein FIELD "anfügen" und das kommt dann "hinter" den "__" Feldern welche von PgDBE angelegt werden.
die daraus entstehenden "Probleme" kann man ja mit PgAdmin "ausprobieren" indem man mit
eine Column löscht welche "vor" den "internen" liegt. da wird sich PgDBE nicht beschweren.
folglich liegt es an meiner Beobachtung die ich 10 Jahren schon gemacht habe.
VERSUCH macht klug ... und nicht blabla
mit ADD COLUMN an man nur ein FIELD "anfügen" und das kommt dann "hinter" den "__" Feldern welche von PgDBE angelegt werden.
die daraus entstehenden "Probleme" kann man ja mit PgAdmin "ausprobieren" indem man mit
Code: Alles auswählen
ALTER TABLExxx DROP COLUMN yyy
folglich liegt es an meiner Beobachtung die ich 10 Jahren schon gemacht habe.
gruss by OHR
Jimmy
Jimmy
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Ich habe übrigens bei pgAdmin4 ein Feature Request gemacht mit der Bitte darum, die Spaltenreihenfolge bei "SELECT * FROM tablename" manuell festlegen zu können. Postgres an sich hat zwar keine offizielle Methode dafür, soweit ich sehen kann, aber die pgAdmin4 Leute haben bestimmt gute Kontakte...
https://redmine.postgresql.org/issues/7162
https://redmine.postgresql.org/issues/7162
Viele Grüße,
David
David
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Nö. Versuch macht nicht immer kluch. Wenn ich versuche, zu fliegen, indem ich von einem Hochhausdach springe, bin ich danach nicht klüger.VERSUCH macht klug ... und nicht blabla
Manchmal ist es sinnvoller, zu fragen. Und genau das habe ich hier gemacht: Angesichts der Tatsache, dass die PGDBE ein ziemlich komplexes System ist, um zwei Welten zu verbinden, frage ich, was die beste Strategie für eine Strukturveränderung im ISAM-PGDBE-Kontext ist. Ich weiß, dass ein simples ALTER TABLE problematisch ist. Und ich will als Antwort sicher kein allgemeines Gesülze darüber hören, wie scheiße dieser Ansatz grundsätzlich ist und wie viel besser es ist, sich auf dem Zahnfleisch durch Megatonnen Code zu beißen, um am Ende etwas zu haben, was sogar JimmyAugeOhr cool findet. Echt, darum geht es nicht. Sondern um die Antwort auf die Frage, die diesen Thread betitelt. Und wenn man das und nur das haben will, nerven Deine immer gleichen Auslassungen sehr. Diese Missionsarbeit ist, bei allem Respekt, komplett idiotisch. Ich weiß nicht, warum Du das unaufhörlich versuchst, aber es ist antipragmatisch. Hier geht es darum, mit Lösungen bestmöglich zu arbeiten. Es geht nicht um einen Glaubenskrieg, welche Lösung die beste ist. Deshalb wäre es nett, wenn Du das etwas zurückfahren könntest. Danke.
Herzlich,
Tom
Tom
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Ich habe keine Probleme mit neuen Feldern hinter den "__" Feldern gehabt, nur mit neuen Feldern hinter einem Volltextsuche-Feld.
Mein Feature Request für pgAdmin4 ist übrigens ein Duplikat , jemand hat dies schon vor einem Jahr gewünscht, es sieht aber nicht leicht aus was Postgres selbst betrifft, interessante Links stehen drin...
Mein Feature Request für pgAdmin4 ist übrigens ein Duplikat , jemand hat dies schon vor einem Jahr gewünscht, es sieht aber nicht leicht aus was Postgres selbst betrifft, interessante Links stehen drin...
Viele Grüße,
David
David
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi Tom,
es ist schon erstaunlich wie du Alaska "verteidigst" und alle "anderen schlecht" machen willst.
sicherlich ist auch die PgCLASS von D & S Software "schlecht" ...
es mag sein das du mit den Einschränkungen klar kommst aber andere zu "verarschen" das es die Lösung des Problem sei was Alaska nach 10 Jahren gefunden hätte ist ein Witz.
JEDE Einschränkung ist ein Eingriff in die Möglichkeiten des Programmierer und führt zu ein Abhängigkeit.
das Konzept von PgDBE ist einfach "sch..." und und daran kannst auch du nichts ändern.
---
hat Alaska in den letzten 10 Jahren eine "neue Mann" geholt der ein PostgreSQL "Experte" ist ?
zeig das PgDBE Konzept mal eine PostgreSQL "Experten" im Postgre-Forum und höre dir die Meinungen an.
das ist das selbe wie mit "Polar Fox" wo Alaska "meinte" das es die Fox Leute damit locken könnte,
Statt sich auf das Level der FOX Leute zu "erheben" wollte Alaska sie nach "Polar FOX" locken was viel "weniger" kann
---
@David : es geht um PgDBE ob man da ein FIELD "hinter" den "internen" einfügen könnte
es ist schon erstaunlich wie du Alaska "verteidigst" und alle "anderen schlecht" machen willst.
sicherlich ist auch die PgCLASS von D & S Software "schlecht" ...
es mag sein das du mit den Einschränkungen klar kommst aber andere zu "verarschen" das es die Lösung des Problem sei was Alaska nach 10 Jahren gefunden hätte ist ein Witz.
JEDE Einschränkung ist ein Eingriff in die Möglichkeiten des Programmierer und führt zu ein Abhängigkeit.
das Konzept von PgDBE ist einfach "sch..." und und daran kannst auch du nichts ändern.
---
hat Alaska in den letzten 10 Jahren eine "neue Mann" geholt der ein PostgreSQL "Experte" ist ?
zeig das PgDBE Konzept mal eine PostgreSQL "Experten" im Postgre-Forum und höre dir die Meinungen an.
das ist das selbe wie mit "Polar Fox" wo Alaska "meinte" das es die Fox Leute damit locken könnte,
Statt sich auf das Level der FOX Leute zu "erheben" wollte Alaska sie nach "Polar FOX" locken was viel "weniger" kann
---
@David : es geht um PgDBE ob man da ein FIELD "hinter" den "internen" einfügen könnte
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Jimmy,
weißt Du, Du hast eine Menge Wissen im Kopf. Aber leider mußt Du auch immer recht haben, in jeder Diskussion, in die Du Dich rein drängst. Und Du mußt Dich sogar noch auf die Hinterbeine stellen und Recht haben wenn längst klar ist, das Du auf dem vollkommen falschen Gebiet argumentierst. Du wärst ein hoch angesehenes Mitglied der Gemeinschaft, wenn Du Dienen guten Ruf nicht immer wieder durch solche irrsinnigen Aktion wieder zerstören würdest.
Mein Rat an Dich wäre also endlich mal nicht immer das letzte Wort haben zu wollen. Und Dich nicht in jede Diskussion einzubringen, auch wenn Du zum eigentlichen Thema dort nichts produktives beizutragen hast (oder wie ein bekannter deutscher Berufssarkastiker mal sagte "Einfach mal die Klappe halten"). Glaub mir, die Forenmitglieder werden es Dir sehr danken. Und Deine unbestreitbaren Verdienste und Kenntnisse um so mehr schätzen.
Übrigens: Wer ist "D & S Software"? Kenn ich nicht die Firma.
Jan
weißt Du, Du hast eine Menge Wissen im Kopf. Aber leider mußt Du auch immer recht haben, in jeder Diskussion, in die Du Dich rein drängst. Und Du mußt Dich sogar noch auf die Hinterbeine stellen und Recht haben wenn längst klar ist, das Du auf dem vollkommen falschen Gebiet argumentierst. Du wärst ein hoch angesehenes Mitglied der Gemeinschaft, wenn Du Dienen guten Ruf nicht immer wieder durch solche irrsinnigen Aktion wieder zerstören würdest.
Mein Rat an Dich wäre also endlich mal nicht immer das letzte Wort haben zu wollen. Und Dich nicht in jede Diskussion einzubringen, auch wenn Du zum eigentlichen Thema dort nichts produktives beizutragen hast (oder wie ein bekannter deutscher Berufssarkastiker mal sagte "Einfach mal die Klappe halten"). Glaub mir, die Forenmitglieder werden es Dir sehr danken. Und Deine unbestreitbaren Verdienste und Kenntnisse um so mehr schätzen.
Übrigens: Wer ist "D & S Software"? Kenn ich nicht die Firma.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Jimmy,
mein erster Impuls war, Dir das hier zu antworten: Du bist leider ein Idiot. Und Dein einseitiger Glaubenskrieg gegen Alaska hat längst pathologische Züge. Möglicherweise brauchst Du Hilfe.
Aber ich will diesem Impuls nicht nachgeben, also versuche ich es sachlich.
Die PGDBE ist nicht der Königsweg, um eine SQL-Anwendung mit Xbase++ zu implementieren. Obwohl es reizvoll ist, auf dem Kenntnisstand, den man über die Jahrzehnte akquiriert hat, einfach sitzen zu bleiben, wäre es für Neuentwicklungen oder sehr kompakte, übersichtliche Projekte möglicherweise schlauer, sich nach anderen Lösungen umzuschauen. Das tue ich übrigens, und das machen andere Leute ganz sicher auch. Ich arbeite in diesem Bereich nicht ausschließlich mit der PGDBE. Ich nutze schon seit langer Zeit u.a. SQLexpress, aber auch andere Lösungen.
Wenn man sehr, sehr große, über die Jahrzehnte gewachsene und immer wieder aktualisierte Anwendungen hat, die bislang mit einer dateibasierten Datenbank arbeiten, dann ist die PGDBE ein mehr als exzellenter Weg, um eine stabile, performante und funktionierende Umstellung auf SQL mit vergleichsweise niedrigem Aufwand zu bewerkstelligen. Das ist verbunden mit dem großen Vorteil, dass man nach und nach den Code für natives SQL optimieren kann, aber vor allem funktioniert es einfach. Es hat noch einige Ecken und Kanten, aber die zu umschiffen ist um einen drei- bis vierstelligen Faktor weniger aufwendig, als beispielsweise mit den von Dir vorgeschlagenen Werkzeugen herumzustochern. Oder Deine nur bis zur Nasenspitze gedachten PP-Ansätze (die inhaltlich auch noch falsch sind) zu verfolgen, oder etwas ähnlich Absurdes zu tun.
Und ich weiß, wovon ich rede. Ich habe Anwendungen mit der PGDBE umgestellt, die riesengroß sind. Sie laufen exzellent, sie sind performant, stabil, das ist einfach überzeugend. Es funktioniert. Es mag immer noch Schwächen haben, es gibt nach wie vor hier und da Probleme, aber keine wirklich hinderlichen. Es ist ein pragmatischer Ansatz, mit dem man arbeiten kann, und zwar richtig gut. Und nichts anderes will ich machen, wollen einige andere machen. Du offenbar nicht, was (für Dich) in Ordnung ist, aber deshalb immer wieder auf den Tisch zu kacken, das ist nichts weiter als infantil. Geh bitte lieber aufs Scheißhaus, ganz für Dich alleine. Danke dafür.
mein erster Impuls war, Dir das hier zu antworten: Du bist leider ein Idiot. Und Dein einseitiger Glaubenskrieg gegen Alaska hat längst pathologische Züge. Möglicherweise brauchst Du Hilfe.
Aber ich will diesem Impuls nicht nachgeben, also versuche ich es sachlich.
Die PGDBE ist nicht der Königsweg, um eine SQL-Anwendung mit Xbase++ zu implementieren. Obwohl es reizvoll ist, auf dem Kenntnisstand, den man über die Jahrzehnte akquiriert hat, einfach sitzen zu bleiben, wäre es für Neuentwicklungen oder sehr kompakte, übersichtliche Projekte möglicherweise schlauer, sich nach anderen Lösungen umzuschauen. Das tue ich übrigens, und das machen andere Leute ganz sicher auch. Ich arbeite in diesem Bereich nicht ausschließlich mit der PGDBE. Ich nutze schon seit langer Zeit u.a. SQLexpress, aber auch andere Lösungen.
Wenn man sehr, sehr große, über die Jahrzehnte gewachsene und immer wieder aktualisierte Anwendungen hat, die bislang mit einer dateibasierten Datenbank arbeiten, dann ist die PGDBE ein mehr als exzellenter Weg, um eine stabile, performante und funktionierende Umstellung auf SQL mit vergleichsweise niedrigem Aufwand zu bewerkstelligen. Das ist verbunden mit dem großen Vorteil, dass man nach und nach den Code für natives SQL optimieren kann, aber vor allem funktioniert es einfach. Es hat noch einige Ecken und Kanten, aber die zu umschiffen ist um einen drei- bis vierstelligen Faktor weniger aufwendig, als beispielsweise mit den von Dir vorgeschlagenen Werkzeugen herumzustochern. Oder Deine nur bis zur Nasenspitze gedachten PP-Ansätze (die inhaltlich auch noch falsch sind) zu verfolgen, oder etwas ähnlich Absurdes zu tun.
Und ich weiß, wovon ich rede. Ich habe Anwendungen mit der PGDBE umgestellt, die riesengroß sind. Sie laufen exzellent, sie sind performant, stabil, das ist einfach überzeugend. Es funktioniert. Es mag immer noch Schwächen haben, es gibt nach wie vor hier und da Probleme, aber keine wirklich hinderlichen. Es ist ein pragmatischer Ansatz, mit dem man arbeiten kann, und zwar richtig gut. Und nichts anderes will ich machen, wollen einige andere machen. Du offenbar nicht, was (für Dich) in Ordnung ist, aber deshalb immer wieder auf den Tisch zu kacken, das ist nichts weiter als infantil. Geh bitte lieber aufs Scheißhaus, ganz für Dich alleine. Danke dafür.
Herzlich,
Tom
Tom
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
@Jimmy
PGDBE gilt bei mir übrigens als gesetzt, die ISAM-Emulation ist der einzige Weg, unsere 30 Jahre alte, sehr komplexe firmeninterne ERP-System mit vertretbarem Aufwand auf Postgres laufen zu lassen, ein anderes Produkt kommt dafür nicht infrage. Falls jemand von Alaska dies liest: Ich bleibe Euch treu, bitte weiterentwickeln!
Ja, ich wiederhole, das geht, eine mit ALTER TABLE nachträglich eingefügte Spalte wird von der PGDBE als Field erkannt, damit habe ich nie ein Problem gehabt, man kann sie lesen und schreiben. Wenn Du was Anderes meinst, dann hast Du Dich leider nicht klar ausgedruckt.
PGDBE gilt bei mir übrigens als gesetzt, die ISAM-Emulation ist der einzige Weg, unsere 30 Jahre alte, sehr komplexe firmeninterne ERP-System mit vertretbarem Aufwand auf Postgres laufen zu lassen, ein anderes Produkt kommt dafür nicht infrage. Falls jemand von Alaska dies liest: Ich bleibe Euch treu, bitte weiterentwickeln!
Viele Grüße,
David
David
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi David
Ihr "kennt" vielleicht nur das Konzept von Alaska aber es sind nicht die einzigen Programmierer die sich (noch) mit xBase beschäftigen.
hm ... dann Frage ich mich wieso Tom diesen Thread eröffnet hat wenn es kein Problem mit PgDBE und "ändern" der Struktur einer Table gibt ? (FIELD mit Index ausgenommem)dtmackenzie hat geschrieben: ↑Di, 08. Feb 2022 9:10 Ja, ich wiederhole, das geht, eine mit ALTER TABLE nachträglich eingefügte Spalte wird von der PGDBE als Field erkannt, damit habe ich nie ein Problem gehabt, man kann sie lesen und schreiben.
die Meinung das es das einzige "ISAM" Konzept ist wäre kann ich nicht zustimmen.dtmackenzie hat geschrieben: ↑Di, 08. Feb 2022 9:10 PGDBE gilt bei mir übrigens als gesetzt, die ISAM-Emulation ist der einzige Weg, unsere 30 Jahre alte, sehr komplexe firmeninterne ERP-System mit vertretbarem Aufwand auf Postgres laufen zu lassen, ein anderes Produkt kommt dafür nicht infrage.
Ihr "kennt" vielleicht nur das Konzept von Alaska aber es sind nicht die einzigen Programmierer die sich (noch) mit xBase beschäftigen.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
hi Tom,
Du hast diesen Thread angefangen mit einer Frage und meine Antwort war das es doch kein Problem sei "on-fly" ein FIELD anzuhängen.
nun ging also darum "raus zu finden" woran das liegen könnte wobei mir dann die "internen" PgDBE FIELD(s) einfielen
ich hatte damals ähnliche Problem, da ich die 5 "internen" FIELD(s) übernommen hatte und es die "letzten 5" waren.
die Logik stimmt natürlich nicht mehr wenn man ein FIELD "hinzufügte"
sobald ich auf ein "mögliches" Problem durch PgDBE hinwies ging es nicht mehr weiter sondern wurde "Poltisch" wo es verschiedene Meinungen gab.
aber eine andere Meinung ist wohl von "einigen" nicht erwünscht und auch nicht was es "ausserhalb" von Xbase++ noch gibt.
wenn man "sieht" was es noch ausserhalb der Xbase++ Welt gibt besteht natürlich die Gefahr das man sein "Glauben" verliert.
---
da David sagte das er keine Probleme mit dem anfügen eines neuen FIELD hätte ist für mich das Thema erledigt.
obwohl du wieder mit einer Beschimpfung angefangen hast werde ich dir antworten
Du hast diesen Thread angefangen mit einer Frage und meine Antwort war das es doch kein Problem sei "on-fly" ein FIELD anzuhängen.
nun ging also darum "raus zu finden" woran das liegen könnte wobei mir dann die "internen" PgDBE FIELD(s) einfielen
ich hatte damals ähnliche Problem, da ich die 5 "internen" FIELD(s) übernommen hatte und es die "letzten 5" waren.
die Logik stimmt natürlich nicht mehr wenn man ein FIELD "hinzufügte"
sobald ich auf ein "mögliches" Problem durch PgDBE hinwies ging es nicht mehr weiter sondern wurde "Poltisch" wo es verschiedene Meinungen gab.
aber eine andere Meinung ist wohl von "einigen" nicht erwünscht und auch nicht was es "ausserhalb" von Xbase++ noch gibt.
wenn man "sieht" was es noch ausserhalb der Xbase++ Welt gibt besteht natürlich die Gefahr das man sein "Glauben" verliert.
---
da David sagte das er keine Probleme mit dem anfügen eines neuen FIELD hätte ist für mich das Thema erledigt.
gruss by OHR
Jimmy
Jimmy
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Jimmy, das habe ich nie behauptet.
Ich habe geschrieben, dass es bei mir als gesetzt gilt.
Das ist bei mir seit letztem Mai kein theoretisches Spielchen mehr, sondern ein Live-Einsatz eines großen, komplexen, unternehmenskritischen Systems.
"Umsatteln" kommt für mich überhaupt nicht in Frage.
Viele Grüße,
David
David
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?
Das hat hier keiner behauptet. Aber immer quatschen lassen, den guten Jimmy. Irgendwann hört er von selbst auf. Selbst wenn er, wie hier gerade, im Duracellhasenmodus ist.Jimmy, das habe ich nie behauptet.
Herzlich,
Tom
Tom