Das nächste Entwicklertreffen findet Anfang Mai in Münster statt - weitere Infos bzw. zur Anmeldung!

PostgreSQL ala Alaska

Alles zum PostgreSQL-Server

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Mo, 02. Jul 2012 4:48

hi,

ich habe mal "frisch" einen PostgreSQL Server installiert und mit meiner Devcon Version verglichen.
die PG Version sind die selben, ich meine was das "Upsize" Tool / pgDBE so "anstellt".

ich habe hier eine DBF mit 4 "Feld"ern per "Upsize" Tool nach PG gebracht.
SQL_RECNO.PNG
SQL_RECNO.PNG (5.46 KiB) 3610 mal betrachtet
es werden zusätzliche "Fields" mit "__" angezeigt.

ich hatte ja das "Problem" bei

Code: Alles auswählen

cSQL := "UPDATE ... WHERE id = cID"
das ich von einem eindeutigen cID "Key" ausgehe wie z.b. Kundennummer.
aber so was habe ich bei meine "Test" DBF ja nicht ...

ich kann aber durchaus auf die "internen Fields" wie "__record" zugreifen
SQL_RowVersion.PNG
SQL_RowVersion.PNG (48.44 KiB) 3610 mal betrachtet
bei den letzten 2 "Fields" haben wir so was wie einen "Index" den man bei "manuellen" Zugriff "pflegen" müsste ...
man sieht wohl auch das da schon einiges durcheinander ist ... kein Wunder bei den Abstürzen ...

was mir auffällt ist die Länge 51 ??? der Inhalt sollte ja

Code: Alles auswählen

      INDEX ON CustNo                    TO CustA
      INDEX ON Upper(LastName+Firstname) TO CustB
sein bei einer DbStruc()

Code: Alles auswählen

Local aStruct := {                                ;
   { "CUSTNO"      ,"C" ,         6,         0 } ,;
   { "MR_MRS"      ,"C" ,        20,         0 } ,;
   { "LASTNAME"    ,"C" ,        20,         0 } ,;
   { "FIRSTNAME"   ,"C" ,        20,         0 } ,;
   { "STREET"      ,"C" ,        30,         0 } ,;
   { "ZIP"         ,"C" ,         5,         0 } ,;
   { "CITY"        ,"C" ,        30,         0 } ,;
   { "STATE"       ,"C" ,         2,         0 } ,;
   { "PHONE"       ,"C" ,        15,         0 } ,;
   { "FAX"         ,"C" ,        15,         0 } ,;
   { "BLOCKED"     ,"L" ,         1,         0 } ,;
   { "TOTALSALES"  ,"N" ,         8,         2 } ,;
   { "NOTES"       ,"M" ,        10,         0 } } 
wie komme ich da auf 51 ?
gruss by OHR
Jimmy

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14597
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: PostgreSQL ala Alaska

Beitrag von Martin Altmann » Mo, 02. Jul 2012 5:01

Moin Jimmy,
dass die Alaska-eigenen Felder mit __ anfangen, ist bekannt. Hatte Steffen so ja auch schon erwähnt! Die brauchen sie, um das Verhalten der Ansteuerung mittels Clipper/dBase-Syntax abbilden zu können.
Dass Deine Index-Felder 11 Zeichen länger sind, sieht man ganz gut auch an dem anderen Indexfeld, auf das Du gar nicht näher eingehst. Am Ende des Wertes steht ein @ gefolgt von einer zehnstelligen Zahl. Ich vermute, dass wird bei deinem 51er Indexfeld genauso sein - sieht man in Deinem Auszug leider nicht!
Ich behaupte mal, dass diese Nummer nach dem @ einfach der OrdKeyNo() entspricht.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Mo, 02. Jul 2012 5:34

Martin Altmann hat geschrieben:dass die Alaska-eigenen Felder mit __ anfangen, ist bekannt. Hatte Steffen so ja auch schon erwähnt!
einmal gesagt und "alle" wissen es ... so was müsste dokumentiert werden und als API für "andere" Sprachen zur Verfügung stehen.
auf die "Table" soll zwar via pgDBE zugegriffen werden aber ich kann es ja kaum einer "anderen" Applikation ( "rechtlich"*** ) verbieten darauf zuzugreifen und zu nutzen.
*** = Passwort
Martin Altmann hat geschrieben:Die brauchen sie, um das Verhalten der Ansteuerung mittels Clipper/dBase-Syntax abbilden zu können.
so was hatte ich mir gedacht als ich "einen Record" identifizieren wollte.
man sollte bei "externen" Zugriffen auch die "internen Fields" evtl. "pflegen" damit pgDBE nicht mit "kryptischen" Meldungen versagt.
Martin Altmann hat geschrieben:Dass Deine Index-Felder 11 Zeichen länger sind, sieht man ganz gut auch an dem anderen Indexfeld, auf das Du gar nicht näher eingehst. Am Ende des Wertes steht ein @ gefolgt von einer zehnstelligen Zahl. Ich vermute, dass wird bei deinem 51er Indexfeld genauso sein - sieht man in Deinem Auszug leider nicht!
Ich behaupte mal, dass diese Nummer nach dem @ einfach der OrdKeyNo() entspricht.
YUP =D>
Dateianhänge
SQL_INDEX_51.PNG
SQL_INDEX_51.PNG (44.21 KiB) 3604 mal betrachtet
gruss by OHR
Jimmy

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14597
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: PostgreSQL ala Alaska

Beitrag von Martin Altmann » Mo, 02. Jul 2012 7:52

Also OrdKeyNo() scheint das doch nicht zu sein - sind ja in beiden Cust-Spalten jeweils die selben Ziffern drin!
Was passiert, wenn Du bei aktivem Index CustA einen Eintrag hinzufügst, der in der Spalte CustNo den Eintrag 22325 hat (und somit vor Deinen aktuell letzten gehört)? Steht dann dort die 000000023? Wahrscheinlich nicht.
Scheint wohl eher die RecNo() zu sein.
Was passiert denn, wenn Du einen Eintrag löscht? Werden die restlichen dann neu durchgezählt?

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

georg
Foren-Administrator
Foren-Administrator
Beiträge: 2255
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL ala Alaska

Beitrag von georg » Mo, 02. Jul 2012 8:03

Guten Morgen,


das sieht aber erschreckend aus. Da kann ich nur hoffen, dass Alaska entsprechende Trigger mit definiert hat, damit diese Felder auch dann aktualisiert werden, wenn ein nicht-Xbase Programm Sätze einfügt oder ändert.

An dieser Stelle hätte ich mir gewünscht, dass man mit manchen xBase-Sonderheiten bricht, wie z.B der recno().


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14632
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: PostgreSQL ala Alaska

Beitrag von brandelh » Mo, 02. Jul 2012 8:26

AUGE_OHR hat geschrieben:auf die "Table" soll zwar via pgDBE zugegriffen werden aber ich kann es ja kaum einer "anderen" Applikation ( "rechtlich"*** ) verbieten darauf zuzugreifen und zu nutzen. *** = Passwort
Martin Altmann hat geschrieben:man sollte bei "externen" Zugriffen auch die "internen Fields" evtl. "pflegen" damit pgDBE nicht mit "kryptischen" Meldungen versagt.
Die Frage ist nicht, ob das "verboten ist", die Frage ist, ob man genau weiß was Alaska mit denen macht :!:
So wie ich Steffen verstanden habe, stellen die per Serverfunktionen und Trigger sicher, dass die internen Felder sauber nachgeführt werden, alles andere währe auch Murks.
Ich würde mich aber nicht auf irgend ein experimentell ermitteltes Verhalten verlassen, intere Felder sind interne Felder und die Funktionsweise kann sich ändern.
Ich werde immer die Felder anlegen, die ich brauche, egal wie ich darauf zugreife :wink:
Georg hat geschrieben:An dieser Stelle hätte ich mir gewünscht, dass man mit manchen xBase-Sonderheiten bricht, wie z.B der recno().
Das kann Alaska nicht, da genau dieses "ich kann mich so verhalten wie die bisherige Technik" deren Hauptverkaufsargument ist.
Aber keiner zwingt dich (oder mich) dazu das auch so zu sehen.

Ich persönlich benenne das primery key Feld entweder RecNo oder eventuell neuer auch RecID und mich zwingt auch niemand solche "UPSIZE DB Monster" zu verwenden ;-)
Es gibt aber wohl Anwender die genau das wollen, gemischter Betrieb zwischen FOXCDX und PGDBE (oder wie die auch heißen mag).
Mit der ODBCDBE konnte ich mich nicht anfreunden, mal sehen :D
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Mo, 02. Jul 2012 19:26

brandelh hat geschrieben:So wie ich Steffen verstanden habe, stellen die per Serverfunktionen und Trigger sicher, dass die internen Felder sauber nachgeführt werden, alles andere währe auch Murks.
Ich würde mich aber nicht auf irgend ein experimentell ermitteltes Verhalten verlassen, intere Felder sind interne Felder und die Funktionsweise kann sich ändern.
wie ich ja ober anfing habe ich in einer "normalen" DBF immer ein "eindeutiges" Key FELD und somit auch die PG Table nach dem MIGriegen. da aber die "Test" Datei kein solches FELD hat war ich auf der Suche nach einer anderen Lösung.

was Alaska mit den zusätzlichen "Fields" macht ist so kaum nachzuvollziehen aber jeder kann die "Fields" sehen und sich denken : die kann ich doch nutzten ...
wenn Alaska aber das ganze nicht dokumentiert bleibt das wieder eine "Interna" und das ganz könnte Alaska ändern wie sie wollen ohne irgendwelche Ankündigungen.

aus diesem Grund habe ich diesen Thread angefangen denn genau dagegen müssen wir uns "jetzt wehren" dass Alaska wieder einmal nicht dokumentiert was für jeden Programmierer selbstverständlich ist.

Warum gibt man das "Upsize" Tool nicht frei wobei ich den Source Code meine !
Wir sollen so eine Tool unsere Daten "anvertrauen" ohne das wir wissen was es damit macht ?

es sollte also in unserem Interesse sein das "jetzt" zu klären bevor die Schnittstelle "so" released wird.
gruss by OHR
Jimmy

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7358
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: PostgreSQL ala Alaska

Beitrag von Tom » Mo, 02. Jul 2012 20:47

Hallo, Jimmy.

Die neue DBE in Verbindung mit dem Migrationstool stellt eine Lösung dar, die aus Xbase-Applikationen heraus Verwendung finden soll. Sie ergänzt die bestehenden DBEs und bietet neue Möglichkeiten, aber es handelt sich um eine zweckgebundene Lösung. Wer anfängt, an den Stored Procedures und Triggern herumzufrickeln oder die Hilfsfelder zu missbrauchen, beschädigt die Integrität des gesamten Modells. Fraglos kommt einem vieles, was da gemacht wurde, auf den ersten Blick ein wenig unelegant vor, aber es ist unterm Strich eine ziemlich bestechende Lösung, um datensatzorientierte Navigation mit einem SQL-Server nutzen zu können, und genau dafür wurde es entwickelt. Wenn Du in den Tabellen herumeierst und dadurch Probleme generierst, ist das zwar originell, aber kein Argument für oder gegen irgendwas. Wenn jemand von außen in den DBF-Tabellen herumpopelt, die eine DBF-basierte Applikation verwendet, kann er ebenfalls Probleme verursachen, aber derlei sollte gefälligst auch unterbleiben, wenn man die Applikation nutzen will, Punkt. Es gibt viele Wege, um funktionierende Systeme lahmzulegen; sogar bei einem schweineteuren Auto genügt ein simpler Nagel. Mir scheint, Du hast zu viele Nägel. :wink:
Herzlich,
Tom

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Mo, 02. Jul 2012 22:36

hi,

um mit den "Nägeln" anzufangen : die liegen auf der Strasse "rum" und ich will ja gerade NICHT mir einen Nagel einfahren.
Komischerweise wird mir immer alles "negative" ausgelegt wobei ich mich doch immer "positiv" über pgDBE ausgesprochen habe !!!

"ich" fummel ja auch nicht mit Excel in einer DBF weil ich es "weiss" ... und DARUM geht es.
wenn Martin sagt das Steffen "da mal was gesagt" hat ist das typisch für das "Kommunikationsproblem"

Die Snapshops sind aus pgAdmin.EXE gemacht, also nicht "irgendein" Tool sondern was bei der Installation von PostgreSQL mit installiert wurde. und JA Alaska hat sich dabei schon was "gedacht" bei den internen "__"fields aber nicht "öffentlich" dokumentiert.




wenn ich meinen "Devcon" PG Server ansehe und den "frisch" installierten PG Server so verhält er sich "anders" nach Einsatz des "Upsize" Tool.
es scheint mir als wenn alle Table die "vorher" vorhanden waren "modifiziert" wurden.
das gilt nicht nur die "Datenbank" MDIDEMO sondern auch für "postgre" oder andere "selbst" angelegte und die dort enthaltenen Table.

bei einem "Server" kann ich kein "geschlossenes" Model einsetzen wenn es den ganzen PG Server "modifiziert" !

klar wenn man nur die Devcon Version im Einsatz hat und einen "frischen" PG Server aufsetzt wird es schon "passen" ...
in der Realität, wenn schon ein PG Server vorhanden ist, wird das geschilderte "Problem" auftauchen und der Admin wird sich wundern ... :badgrin:
gruss by OHR
Jimmy

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7358
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: PostgreSQL ala Alaska

Beitrag von Tom » Mo, 02. Jul 2012 22:47

Hallo, Jimmy.

Dir ist bewusst, dass Du mit einem "Early Preview" arbeitest, ja? Das gilt auch und insbesondere für die Dokumentation. Außerdem hat Steffen beim Forentreffen und bei der DevCon ausgeführt, dass es eine von Alaska konfigurierte Version des Servers gibt/geben wird, die bitteschön verwendet werden sollte, um genau solche Irritationen, wie Du sie jetzt erwähnst, zu vermeiden. Man kann übrigens mehrere PostGre-Server parallel installieren.

Wie sagte Arlo Guthrie? "You can't have a light without a dark to stick it in". Ja, wir bekommen "natives" SQL, dazu noch für einen recht performanten Server, der kostenlos erhältlich ist, die Konten unserer Kunden also nicht über Gebühr belastet. Nein, es ist keine Blackbox, die idiotensicher verschraubt ist. Wenn jemand am Server herumdaddelt und Blödsinn veranstaltet, werden unsere Apps krepieren. Dasselbe kann man mit jedem SQL-Server veranstalten, der mit Tabellen, Triggern und Stored Procs versehen wurde, die für eine bestimmte Applikation oder einen bestimmten Applikationstypen installiert wurden.
Herzlich,
Tom

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Di, 03. Jul 2012 0:03

Tom hat geschrieben: Dir ist bewusst, dass Du mit einem "Early Preview" arbeitest, ja? Das gilt auch und insbesondere für die Dokumentation.
deshalb spreche ich das Thema JETZT an damit es "später" auf der Liste nicht ganz nach hinten rutscht.
dir ist ja wohl auch klar das genau "das" die Sachen sind die man eben mit einer solche Build macht denn zum "erkunden" sind die ja gedacht.
Tom hat geschrieben:Außerdem hat Steffen beim Forentreffen und bei der DevCon ausgeführt, dass es eine von Alaska konfigurierte Version des Servers gibt/geben wird, die bitteschön verwendet werden sollte, um genau solche Irritationen, wie Du sie jetzt erwähnst, zu vermeiden.
interessant ... ich habe nirgends auf den Videos was davon gesehen / gehört.
wieder ein "Kommunikations" Problem ? oder ist die Information nur einer Elite vorbehalten ?

ich weiss nur, auf Anfrage im Newsforum, das ich eine v8.3 Version verwenden soll
Tom hat geschrieben:Man kann übrigens mehrere PostGre-Server parallel installieren.
klar und MySQL dazu ... das "löst" nicht das Problem das man auf "Datenbanken" eben "gemeinsam" zugreifen will.
Tom hat geschrieben:Wenn jemand am Server herumdaddelt und Blödsinn veranstaltet, werden unsere Apps krepieren. Dasselbe kann man mit jedem SQL-Server veranstalten, der mit Tabellen, Triggern und Stored Procs versehen wurde, die für eine bestimmte Applikation oder einen bestimmten Applikationstypen installiert wurden.
da braucht keiner "herum daddeln" oder hält du eine SQL Table für "unzerstörbar" ?
ich habe unter Xbase++ v2.0.426 mit pgDBE den Absturz verursacht weil ich "Umlaute" verwendet habe.

erst danach habe ich mit der "native" PG Schnittstelle angefangen um einen "Vergleich" zu bekommen
durch das einarbeiten in die "native" PG Schnittstelle habe ich die "Extras" entdeckt die einem Xbase++ User normal nicht "sieht".
jetzt kann ich mir also einen "Super-GAU" vorstellen was mit den "Table" passieren könnte und mir überlegen wie ein "Werkzeug" für solche Fälle aussehen sollte.

das pgAdmin.exe ist wohl "das" Tool für die Table, aber wenn das Tool dir nichts mehr anzeigt ... was dann ?
der Rest sind eher jetzt "Rettungsversuche" um zu sehen "wie" man etwas "repariert" ... so wie mit DBU.EXE
gruss by OHR
Jimmy

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Di, 03. Jul 2012 23:06

hi,

wer eine Meinung von Boris Borzic zu diesem Thema lesen möchte sollte sich mal bei Pablo im Forum unter

AUGE_OHR
22. Juni 2012
xfree.public
LibPG4xb -> "Wrapper" Class

seine Bemerkungen ansehen. Es sind die selben Erfahrungen die wir beide gemacht haben nur das Boris damals schon "verstand" was harbour mit SQLRDD gemacht hat und ich erst "jetzt" anfange das ganze zu verstehen.
gruss by OHR
Jimmy

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL ala Alaska

Beitrag von AUGE_OHR » Mi, 04. Jul 2012 22:38

hi

ich hab, nach Hinweis von Alaska, in den Help Files gesucht und in pg20.chm tatsächlich was gefunden.

was "__deleted" und "__record" angeht ist das ja klar, aber "__rowversion", was ja oben im Snapshot <> 0 ist, wird nur "angedeutet".
mich interessiert dabei "wie" ich es "reparieren" kann/darf ... wenn ich nicht mehr per pgDBE an die Table komme.

p.s. die Frage hab ich auch im Alaska Newsforum gestellt.
gruss by OHR
Jimmy

Antworten