Inoffizielles deutsches Xbase-Forum

Ich hatte schonmal eine Thread eröffnet, in dem ich um die Erfahrung mit Xbase++ 2.0 und Postgres nachgefragt hatte. Wie es aber so ist, ich finde ihn nicht mehr. Also einen neuen aufmachen.
meine Frage hier jetzt, in wie weit ünterstützt die 2.0er Version eigentlich postGres? Nur im Umfeld der Alaska Idee, wenn man die SQL DB wie eine DBF verwalten will, oder kann/könnte man die PostGres DB genau so ansprechen, wie es eigentlich vorgesehen ist und alles über reine SQL Befehle machen? Welche Einschränkungen gäbe/gibt es? Wie verhält sich dann das Tempo der Zugriffe darauf? Wie kompliziert wäre/ist es die SQL Befehle an die DB zu senden? Und vor allen Dingen, wie sieht das Handling dann in der Praxis aus?
Alles weitere ergibt sich dann mit den Antowrten hier....

Manfred,

Xbase++ 2.0 kann halt SQL. Unabhängig welches. Also auch PostreSQL.

Das Besondere an PostreSQL in Xbase++ 2.0 ist halt nur, das Alaska eine PGDBE mitliefert, wo man die Tabellen auch mit Db..()-Funktionen ansprechen kann. Man also im Prinzip seine alte Anwendung läßt wie sie ist, aber doch auf einer SQL statt dbf arbeitet. Das läuft zwar schon besser als früher, aber so ganz richtig rund noch immer nicht - siehe all die offenen PDR zu dem Thema. Die Performance ist nicht so wie reinrassiges SQL. Auch klar,w eil da die Übersetzungseben zwischen steckt. Und der Upsizer ist bei Weitem nicht so vollautomatisch wie von Alaska angepriesen. Aber es bietet halt die Möglichkeit, schon jetzt mal alles nach SQL zu bringen, und dann die Zugriffe nach und nach auf SQL umzustellen.

Andersrum ist das einfacher. Eine dbf mit SQL-Anweisungen ansprechen. Hab ich schon mal gemacht mit einigen wenigen SQL-Anweisungen, dabei aber subjektiv nicht wirklich große Performance-Unterschiede festgestellt. Was ansich auch logisch ist, weil ja die Tabellen immer noch die gleichen sind, das ist halt kein SQL-Server, der einem Arbeit auf dem Client abnimmt.

Jan

Hallo, Jan -

da Du da anscheinend tiefer drinsteckst ... Ich vermute mal, Manfred will wissen, ob man z.B. auf einen MySQL-Server zugreifen kann, oder auf PostGRE ohne PGDBE?

Georg,

Du bist doch hier der SQL-Exporte. Nicht ich. Ich hab nur mal das Upsizing auf die PGDBE getestet. Und SQL-Anweisungen auf dbf getestet. Und auch SQL-Anweinsungen auf proprietär verwaltete dbf im ADS gemacht. Alles andere weiß ich auch nur aus den Docs, Vorträgen von Alaska, und Gesprächen mit den Alaska-Jungs.

Alaska hat halt den kompletten Code von SQlite in Xbase++ integriert (einer der Gründe für den enormen Ansprung der Codezeilen von 1.9 auf 2.0), deswegen kann das jetzt halt SQL. Die Interaktion mit dbf etc. mussten die natürlich ergänzen, und das hat schon mal heftig gehakt. Wird aber auch immer besser.

Jan

Hallo, Jan -

also, ich habe lediglich meinen Code von 1.9 auf die 2.0 portiert und verwende weiterhin Hector's MySQL-Wrapper.

Der Hinweis auf die SQLite-Implementierung ist interessant, das war mir bisher entgangen. Hier verwende ich (z.B. zum Zugriff auf Cookies in Firefox) eine Klasse, die Pablo mal geschrieben hat. Das werde ich mir mal anschauen.

Aber nativer Zugriff auf SQL-Server ist demnach noch nicht möglich, wenn ich das richtig verstehe. Naja, kommt vielleicht ja noch mal

Georg,

warum sollte das nicht gehen? Du must eine Connection zum SQL-Server aufbauen, und kannst dann SQL-Anweisungen dahin abschicken. Schau Dir da mal CREATE CONNECTION in der Xbase++-Hilfe an.

Und nein - sowas habe ich noch nicht getestet. Wie gesagt habe ich ein paar Dinge mal für mich ausprobiert. Aber noch nie selber direkt auf eine reinrassige SQL gearbeitet.

Jan

Hallo, Jan -

CREATE CONNECTION bezieht sich nur auf ODBC-Verbindungen, da dort eine DSN (Data Source Name) verlangt wird, eine Verbindung zu einem beliebigen SQL-Server(-Typ) ist so wohl nicht möglich.

Aber auf jeden Fall "Danke!" für Deine Hinweise.

Hallo Georg,

OK, Danke für den Hinweis. Wie gesagt, sooo tief häng ich in der SQL-Geschichte dann auch wieder nicht drin, eher sehr viel weniger. Beim ADS mach ich das per DAC-Session, aber da braucht man dann halt auch die ADSDBE (oder bei PostgreSQL die PGDBE), oder es geht halt auch wieder per ODBC. Wäre in der Tat die Frage ob, und wenn ja wie, man direkt auf eine SQL gehen könnte.

Jan

Jan hat geschrieben: ↑Do, 18. Okt 2018 15:44 ...Wäre in der Tat die Frage ob, und wenn ja wie, man direkt auf eine SQL gehen könnte.
Jan

siehste und das war das was ich wissen wollte. Ob man mit der 2.0 evtl. direkt an die Postgres gehen kann oder "nur" über die PGDbe im Xbase++ Format.

Letzteres.

Das stimmt so nicht ganz.

in der Anleitung würde ich auf den ersten Blick lesen, das man das kann um Schritt für Schritt auf reines SQl umzusteigen. Ich habe sie aber nur überflogen und noch nicht komplett zuende gelesen. das wäre ja dann ähnlich dem ADS. Da kann man auch anfänglich mischen um dann nach und nach auf SQl umzustellen.

Tom,
was stimmt nicht so ganz? Es ging nicht um ODBC. Es ging auch nicht darum, was mit Xbase++ 3.0 geplant ist.

Viele Grüße,
Martin

Manfred hat geschrieben: ↑Do, 18. Okt 2018 17:52 Ob man mit der 2.0 evtl. direkt an die Postgres gehen kann oder "nur" über die PGDbe im Xbase++ Format.

man muss wohl die PgDBE laden denn sonst kann man keine Connection aufbauen.
danach muss man aber keinen ISAM-Emulation Code schreiben sondern kann auch SQL Syntax verwenden.

Code: Alles auswählen

PROCEDURE main
#include "dac.ch"

DbeLoad("pgdbe")
DbeSetDefault("pgdbe")

cConnStr := "DBE=pgdbe;server=localhost;db=mdidemo;uid=postgres;pwd=postgres"
oSession := DacSession():New(cConnStr)
IF(!oSession:IsConnected())
 MsgBox("Connection failed ("+Var2Char(oSession:GetLastMessage())+")")
 QUIT
ELSE
 MsgBox("Connected to PostgreSQL server")
ENDIF

IF(!Table("Customer"))
  MsgBox("No customer table")
ENDIF

SELECT * FROM customer WHERE lastname = "miller" ORDER BY lastname INTO atemp VIA oSession
SELECT atemp

RETURN

Jimmy,

genau.

Aber das geht halt nur mit ADS und PostgreSQL. Weil Alaska nur dazu eine DBE mitliefert. Alle anderen SQL-Daetnbanken gehen dann anscheinend nur per ODBC.

Jan

und damit ist die Frage von Manfred beantwortet. Ja, man kann mittels der PGDBE (m. M. n.) alle SQL-Befehle an einen (auch aktuellen) PostgreSQL schicken und verarbeiten.

Wir machen neue Programmteile nur noch über unsere SQL-Klasse (dacsession()) und sprechen damit den PostgreSQL direkt an. Klar sind da noch trigger und ähnliches von Alaska dazwischen, die nutzen wir aber nicht, da wir kein ISAM damit machen.

Läuft sehr gut und sehr performant, bei uns selbst seit 03.2016, bei unseren Kunden seit 01.2017. Die vielen PDRs dazu haben wir über unsere Klasse schön abfangen können, viele sind ja eh inzwischen geschlossen.

Select-Befehle laufen z. B. über

Code: Alles auswählen

oSession:executeQuery()

insert über

Code: Alles auswählen

oSession:executeStatement()

Also heißt das jetzt jetzt auf Kohlenpottplatt:
Datt Dingen kann man auch für SQL Server benutzen. Wenn auch nur für PostGres, aber man kann eine echte SQL Datenbank damit betreiben. Benötigt kein SQlExpress, kein ODBC oder sonstige Hilfsmittel.
Gut zu wissen.

So isses.

Und das funktioniert auch (wie übrigens auch die ISAM-Emulation inzwischen fast richtig gut funktioniert). Sogar sehr performant.

so wie ich gerade sehe, scheint doch nicht alles abgedeckt zu sein.
https://www.xbaseforum.de/viewtopic.php?f=114&t=11589

und wie muß ich jetzt die Befehle absenden an den Postgres Server innerhalb Xbase++ wenn ich beides parallel nutzen will für eine Übergangszeit?

Laß Dich nicht verwirren Manfred, Du kannst beides parallel nutzen. Wenn Du möchtest, kannst Du auf die Dbf wie bisher (dbUseArea), als auch mit SQL-Befehlen zugreifen. Um auf SQL-Tabellen zuzugreifen nimmst Du z.B.

Code: Alles auswählen

oStmt  := DacSqlStatement( ::DacSession ):fromChar( "select..." )
cAlias := oStmt:Build():Query( USQL_RESULT_WORKAREA )

Das Ergebnis der Abfrage ist in einer Rückgabedatei enthalten die Du via (cAlias)-> ansprechen kannst. Welche Felder die Datei enthält, hast Du im SELECT-Statement festgelegt. Beispiele:

Code: Alles auswählen

oStmt  := DacSqlStatement( ::DacSession ):fromChar( "select feld1, feld2 from tabelle" )

liefert Dir eine Datei mit zwei Feldern (feld1,feld2) gleichen Namens aus 'tabelle'.

Code: Alles auswählen

oStmt  := DacSqlStatement( ::DacSession ):fromChar( "select * from tabelle" )

liefert Dir alle Felder aus 'tabelle' mit deren Namen in der SQL-Tabelle.

Da es in SQL-Tabellen deutlich mehr Feldtypen als in DBF-Dateien gibt und einen in DBFs unbekannten Wert NULL, kommt es durch das Einlesen in die temp. Datei zu Konvertierungen!

Code: Alles auswählen

oStmt  := DacSqlStatement( ::DacSession ):fromChar( "select feld1, feld2..." )
cAlias := oStmt:Build():Query( USQL_RESULT_WORKAREA )

aObjects := Array( (cAlias)->(LastRec()))
(cAlias)->( dbEval({|| aObjects[ ++ nElement ] := _scatterObject() }))

(cAlias)->( dbCloseArea() )

Mit diesen Zeilen, liest Du eine SQL-Tabelle (oder mehrere) in ein Array und wandelst dabei die Datensätze in DataObjects um. Beachte, dass Du die temp. Datei am Ende schließen solltest. Frank++ hat in einer früheren Nachricht eine kürzere Variante, um die Datensätze in DataObjects umzuwandeln, aufgezeigt. Bei mir hat diese in einer älteren Version von XBase noch zu Problemen geführt.

Ich hoffe Deine Frage richtig verstanden zu haben.

muß ich das alles eingeben um einen Befehl abzuschicken? Z.B. Insert?

ohne Fehlerbehandlung reichen zwei Zeilen:

Code: Alles auswählen

oStmt   := DacSqlStatement( ::DacSession ):fromChar( cStatement )
nZeilen := oStmt:Build():execute()

nZeilen enhält die Anzahl an Reihen (Datensätzen) die eingetragen wurden.

klappt nicht. Was ist denn mit ::dacSession gemeint?
ich bekomme "Session does not support SQL" zurück

alles klar, klappt. Problem war anfänglich das die pgdbe.ch fehlte. dann fehlten rechte Dann klappte es.

Inoffizielles deutsches Xbase-Forum

PostGres und Xbase++2.0 [ERLEDIGT]

PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]

Re: PostGres und Xbase++2.0 [ERLEDIGT]