PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
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:

PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

hi

ich habe keine Erfahrung mit der ISAM-Emulation aber "normal" muss man kein

Code: Alles auswählen

DROP TABLE 
ausführen um die Structure zu ändern

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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

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.
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

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

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
der PRIMARY KEY wird durch nextval() auf den aktuellen Stand gebracht.
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

Wo kommt das her, Jimmy?
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

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

Code: Alles auswählen

DROP TABLE
probieren es doch einfach mal mit PgAdmin
gruss by OHR
Jimmy
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Werner_Bayern »

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.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
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?

Beitrag von dtmackenzie »

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...
Viele Grüße,
David
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

@David: Danke für den Hinweis!
@Jimmy: Immer das gleiche Blabla.
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

hi Tom,

VERSUCH macht klug ... und nicht blabla [-X

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
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.
gruss by OHR
Jimmy
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
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?

Beitrag von dtmackenzie »

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
Viele Grüße,
David
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

VERSUCH macht klug ... und nicht blabla
Nö. Versuch macht nicht immer kluch. Wenn ich versuche, zu fliegen, indem ich von einem Hochhausdach springe, bin ich danach nicht klüger.

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
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
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?

Beitrag von dtmackenzie »

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 :oops:, 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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

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 :lol:

---

@David : es geht um PgDBE ob man da ein FIELD "hinter" den "internen" einfügen könnte
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Jan »

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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

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.
Herzlich,
Tom
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
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?

Beitrag von dtmackenzie »

@Jimmy
AUGE_OHR hat geschrieben: Di, 08. Feb 2022 5:53 es geht um PgDBE ob man da ein FIELD "hinter" den "internen" einfügen könnte
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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

hi David
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.
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 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.
die Meinung das es das einzige "ISAM" Konzept ist wäre kann ich nicht zustimmen.

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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von AUGE_OHR »

hi Tom,
Tom hat geschrieben: Di, 08. Feb 2022 7:52 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.

Aber ich will diesem Impuls nicht nachgeben, also versuche ich es sachlich.
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 :idea:
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" #-o

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
Benutzeravatar
dtmackenzie
Rekursionen-Architekt
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?

Beitrag von dtmackenzie »

AUGE_OHR hat geschrieben: Sa, 12. Feb 2022 20:29 die Meinung das es das einzige "ISAM" Konzept ist wäre kann ich nicht zustimmen.
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
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: PGDBE: Beste Strategie für Tabellenstrukturänderungen im ISAM-Modus?

Beitrag von Tom »

Jimmy, das habe ich nie behauptet.
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.
Herzlich,
Tom
Antworten