Inoffizielles deutsches Xbase-Forum

Moin,

bei einem Einsatz von

oStmt := DacSqlStatement( ::DacSession ):fromChar( "select * from artikel" )
cAlias := oStmt:Build():Query( USQL_RESULT_WORKAREA )

erwarte ich, das

(cAlias)->(Len(dbStruct()))

die gleiche Anzahl an Feldern zurückgibt, wie die Tabelle 'artikel' Spalten enthält; tut sie aber nicht: Es ist stets ein Feld weniger. In der Ergebnisdatei fehlt immer die letzte Spalte (unabhängig von der Tabelle und dem Spaltentyp).

Ermittelt in Version 2.0 Pbuild 1159; ist es in der aktuellen Version auch so?

Servus Klaus,

12-Version PG-Server? Dann nein, ist seit 1185 gefixed.
Mit < 12 hast den Fehler auch mit Deiner Xbase++ - Version nicht.

Servus Werner und Danke,

ich arbeite mit der 12er Version. Interessant, dass der Fehler mit einer älteren Version nicht auftreten würde. Das bedeutet doch, dass bei einer neuen Datenbank-Version vor dem Einsatz mit XBase unbedingt geprüft werden sollte, ob alle Abfragen noch genauso funktionieren wie erwartet. Dies wiederum schreit nach einer Testanwendung die anhand einer Testdatenbank und einer Datei mit allen erwarteten Ergebnissen die Rückgaben der neuen Version vergleicht und Abweichungen meldet.

Bitte und ja, wäre sicherlich nicht verkehrt. Bisher haben wir bei uns das immer selber getestet, also neue PG-Versionen werden zuerst grundlegend mit bestehenden Test-Anwendungen und danach mit unseren Inhouse-Anwendungen getestet.

hi,

Klaus Schuster hat geschrieben: ↑Fr, 01. Mai 2020 6:57 ich arbeite mit der 12er Version. Interessant, dass der Fehler mit einer älteren Version nicht auftreten würde. Das bedeutet doch, dass bei einer neuen Datenbank-Version vor dem Einsatz mit XBase unbedingt geprüft werden sollte, ob alle Abfragen noch genauso funktionieren wie erwartet.

die PostgreSQL v12 gibt es doch nur noch als 64 Bit Version, oder ?
unter Xbase++ v2.x wird doch IMHO der Source der 32 Bit Version genutzt.

nun gehst du davon aus da du mit "jeder" 32 Bit Client Version auf einen PG-Server zugreifen kann ...

---

ich nutze es ja "native" d.h. ich verwende

v7.2.1
libpq.dll

v8.4.2
comerr32.dll
gssapi32.dll
k5sprt32.dll
krb5_32.dll
libeay32.dll
libiconv-2.dll
libintl-8.dll
libpq.dll
ssleay32.dll

v9.5.2 - v11
libeay32.dll
libecpg.dll
libecpg_compat.dll
libiconv-2.dll
libintl-8.dll
libpgtypes.dll
libpq.dll
libxml2.dll
libxslt.dll
ssleay32.dll
zlib1.dll

nun kann ich im Prinzip mit der alten libpq.dll v7.2.1 auf der PG v11 Server zugreifen und arbeiten ...
aber das gibt evtl. Problem wenn noch "andere" am PG-Server hängen die eine andere Client DLL Version verwenden.

deshalb habe ich verschiedene DLL "Sätze" für den entsprechenden PG-Server.

Klaus Schuster hat geschrieben: ↑Fr, 01. Mai 2020 6:57 Dies wiederum schreit nach einer Testanwendung die anhand einer Testdatenbank und einer Datei mit allen erwarteten Ergebnissen die Rückgaben der neuen Version vergleicht und Abweichungen meldet.

ich würde also mal bei Alaska anfragen welche PG-Version für Xbase++ v2.x "freigegeben" ist.

Hallo Jimmy

schau dir mal den Sourcecode von LIBPQ an. Diesen findest du im Sourcetree: /postgresql-12.2/src/interfaces/libpq

Da siehst du dass diese zum übsersetzten als 32 oder 64 Bit Version vorbereitet ist. Am einfachsten kannst du dies mit VC auch selbst tun.

Auch die 32 Bit libpq Version kann 64 Bit Wert zurückgeben. Mit den neueren xbase++ musst du dazu die extern Kommandos verwenden oder die entsprechenden Funktionen von ot4xb. Mit dllcall() gehen 64 Bit returnwerte wirklich nicht.

die PostgreSQL v12 gibt es doch nur noch als 64 Bit Version, oder ?

Das bezieht sich nur auf den Server.

Eine aktuelle LIBPQ als 32 Bit findest du auch immer in PGAdmin4......

hi Carlo,

wenn man PgDBE mit der ISAM-Emulation einsetzt geht es doch wohl über die "eingebaute" LibPQ und die ist sicherlich NICHT auf v12 Stand.

---

meiner Aufzählung kann man entnehmen welche "zusätzlichen" DLL man für die LibPQ.DLL benötigt.
da die nicht bei Xbase++ v2.x enthalten sind kann man also darauf schliessen welchen Stand die "eingebaute" LibPQ hat.

nun war es immer schon schlecht wenn man verschiedene Versionen verwendet ... auch wenn man es nicht "merkt" ...
ich kann also nur empfehlen PgDBE mit der von Alaska "freigegebenen" Version zu betreiben.

AUGE_OHR hat geschrieben: ↑So, 03. Mai 2020 2:40 wenn man PgDBE mit der ISAM-Emulation einsetzt geht es doch wohl über die "eingebaute" LibPQ und die ist sicherlich NICHT auf v12 Stand.

Anscheinend ist es die 8.3.1.8104 aus 2008........

Das Problem kann auch auftreten, wenn eine Spalte einen Typ hat, der nicht von XBase konvertiert wird (z.B. UUID). Die Lösung (Dank Werners Hilfe) besteht in

4.2.9. Type Casts

A type cast specifies a conversion from one data type to another. PostgreSQL accepts two equivalent syntaxes for type casts:

CAST ( expression AS type )
expression::type

The CAST syntax conforms to SQL; the syntax with :: is historical PostgreSQL usage.

When a cast is applied to a value expression of a known type, it represents a run-time type conversion. The cast will succeed only if a suitable type conversion operation has been defined. Notice that this is subtly different from the use of casts with constants, as shown in Section 4.1.2.7. A cast applied to an unadorned string literal represents the initial assignment of a type to a literal constant value, and so it will succeed for any type (if the contents of the string literal are acceptable input syntax for the data type).
https://www.postgresql.org/docs/current ... sions.html

ich darf mit einem Beispiel ergänzen: Liefert dann die Spalte plz als Text zurück.

Hallo Werner,

der Einsatz von :: entspricht nicht dem SQL-Standard:

The CAST syntax conforms to SQL; the syntax with :: is historical PostgreSQL usage.

oder so