SEO

Hello,

I'm trying to use PostgreSQL via ODBC under Windows
and IBM VisualAge Smalltalk. Normally ODBC works
pretty well, but I've found two problems with the
ODBC driver of PostgreSQL, which makes the whole
thing not working:


a) All column names are returned from the database
in lowercase and not in the form the client send
then when doing the "create table ..." statement.

Which leads to the problem, that other frameworks
on top of it do not find their columns do make the
oo-rdbms mapping stuff.

b) All strings returned by the ODBC driver are defined
in a buffer, which is offered to the ODBC subsystem
as a string doubled in size - though I told the
databaase NOT to create a UNICODE db.

An example: a column has the result type char(15). The
ODBC drivers put the result of this column into a
memory with a size of 30 characters.

The ODBC subsystem now thinks: fine - I've a character
column with size 30 and creates a string 30 characters
long and one gets 15 corrects characters and 15 "0" (null)
bytes.

I've never seen this behaviour with other ODBC drivers
I've used so far, therefore I think, this is pretty
strange behaviour.

I'm using the 8.0.3 database and the 8.0.1.2 drivers.

Any ideas ???


Marten Feldtmann

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Hi Marten,

i am using PostgreSQL 8.0.3 an ODBC 8.0.1.2 with VisualWorks 7. I am
using a UNICODE database (with the same client connect datatype) and all
works fine because of the result data aspect. It seems, that other than
UNICODE make problems in any case.

Josef Springer

Marten Feldtmann wrote:

> Hello,
>
> I'm trying to use PostgreSQL via ODBC under Windows
> and IBM VisualAge Smalltalk. Normally ODBC works
> pretty well, but I've found two problems with the
> ODBC driver of PostgreSQL, which makes the whole
> thing not working:
>
>
> a) All column names are returned from the database
> in lowercase and not in the form the client send
> then when doing the "create table ..." statement.
>
> Which leads to the problem, that other frameworks
> on top of it do not find their columns do make the
> oo-rdbms mapping stuff.
>
> b) All strings returned by the ODBC driver are defined
> in a buffer, which is offered to the ODBC subsystem
> as a string doubled in size - though I told the
> databaase NOT to create a UNICODE db.
>
> An example: a column has the result type char(15). The
> ODBC drivers put the result of this column into a
> memory with a size of 30 characters.
>
> The ODBC subsystem now thinks: fine - I've a character
> column with size 30 and creates a string 30 characters
> long and one gets 15 corrects characters and 15 "0" (null)
> bytes.
>
> I've never seen this behaviour with other ODBC drivers
> I've used so far, therefore I think, this is pretty
> strange behaviour.
>
> I'm using the 8.0.3 database and the 8.0.1.2 drivers.
>
> Any ideas ???
>
>
> Marten Feldtmann
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Actually this is still a point I have to investigate. To made
all stuff working in a correct way I need another information
about how much bytes actually used ... or I need an information
that I have to deal with UNICODE stuff.

Within the ODBC driver interface I deal with cbLength and
cbPrecision (information delivered by the ODBC drivers). The
first one tells the interface, how much bytes are reserved
for this column and cbPrecision tells me, what was the length
when executing the create statement.

Therefore under PostgreSQL it's:

For CHAR(15), cbLength is ALWAYS 30 and cbPrecision is always
15.

Both information are not enough - I need to know, how much of
cbLength of this buffer I must use to create the string (and
of course how to interpret the byte stream: single byte character
or doubule byte character) - or cbLength changes it's value
depending on the

Perhaps it would be better to have

CHAR(15) -> cbLength = 15, cbPrecision = 15 (if single-byte database)
CHAR(15) -> cbLength = 30, cbPrecision = 15 (if unicode database)

but there also seem to be other parameters within the ODBC
specs to get this information - I just have not found the overall
picture.

Marten

Josef Springer schrieb:

> Hi Marten,
>
> i am using PostgreSQL 8.0.3 an ODBC 8.0.1.2 with VisualWorks 7. I am
> using a UNICODE database (with the same client connect datatype) and
> all works fine because of the result data aspect. It seems, that other
> than UNICODE make problems in any case.
>
> Josef Springer
>
>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Perhaps you might remember my tests with
PostgreSQL and IBm VisualAge Smalltalk.

I mentioned my problems with column lengths
and stuff like this.

I still testing (from time to time) with
the 8.0.3 database and use the newest
8.01.00.03 libpq ODBC drivers and now
the situation is getting worse :-((((

IBM Smalltalk is now not able to get the
correct column size for strings any more.

I always get either 254 bytes or 508 bytes
as column size.

We have a table like:

create table "TPERSON" ("ALLCSTVIEW" CHAR(1)
.....

Now IBM Smalltalk calls OdbcSQLDescribeCol
and gets 254 for this column as size in the
return parameter cbPrecision.

And the alternate call via OdbcSQLColAttribute
with parameter Sql_Column_Lengthreturns 508.

Actually this is true for ALL string columns

The PostgreSQL drivers seem strange for me ...
I've done work with other database systems
via this ODBC library, but PostgreSQL does
not give me any real success ....

If anyone has any help ....

Marten

>
>
> b) All strings returned by the ODBC driver are defined
> in a buffer, which is offered to the ODBC subsystem
> as a string doubled in size - though I told the
> databaase NOT to create a UNICODE db.
>
> An example: a column has the result type char(15). The
> ODBC drivers put the result of this column into a
> memory with a size of 30 characters.
>
> The ODBC subsystem now thinks: fine - I've a character
> column with size 30 and creates a string 30 characters
> long and one gets 15 corrects characters and 15 "0" (null)
> bytes.
>
> I've never seen this behaviour with other ODBC drivers
> I've used so far, therefore I think, this is pretty
> strange behaviour.
>
> I'm using the 8.0.3 database and the 8.0.1.2 drivers.
>
> Any ideas ???
>
>
> Marten Feldtmann
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>


--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Here a partial answer. The reason was the special
ODBC driver libpq I used.

I installed the 08.01.0101 driver and now the base
routines work again.

Strange, that I get a difference ration of 3:1 between
columnLength and columnPresicion with string based
columns.

a char(1) returns the columnPrecision of 1, but a column
length of 3 which I do not understand.


Marten



Marten Feldtmann schrieb:

> Perhaps you might remember my tests with
> PostgreSQL and IBm VisualAge Smalltalk.
>
> I mentioned my problems with column lengths
> and stuff like this.
>
> I still testing (from time to time) with
> the 8.0.3 database and use the newest
> 8.01.00.03 libpq ODBC drivers and now
> the situation is getting worse :-((((
>
> IBM Smalltalk is now not able to get the
> correct column size for strings any more.
>
> I always get either 254 bytes or 508 bytes
> as column size.
>
> We have a table like:
>
> create table "TPERSON" ("ALLCSTVIEW" CHAR(1)
> ....
>
> Now IBM Smalltalk calls OdbcSQLDescribeCol
> and gets 254 for this column as size in the
> return parameter cbPrecision.
>
> And the alternate call via OdbcSQLColAttribute
> with parameter Sql_Column_Lengthreturns 508.
>
> Actually this is true for ALL string columns
>
> The PostgreSQL drivers seem strange for me ...
> I've done work with other database systems
> via this ODBC library, but PostgreSQL does
> not give me any real success ....
>
> If anyone has any help ....
>
> Marten
>
>
>


--
Marten Feldtmann - Germany - Software Development
Information regarding VA Smalltalk and DMS-system
"MSK - Mien Schrievkrom" at: www.schrievkrom.de


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster