public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jon Raiford <[email protected]>
To: Wal, Jan Tjalling van der <[email protected]>
To: Marsupilami79 <[email protected]>
To: [email protected] <[email protected]>
Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count?
Date: Fri, 25 Nov 2022 02:58:25 +0000
Message-ID: <SA1PR17MB5350D74A659E421C12CA9125BE0E9@SA1PR17MB5350.namprd17.prod.outlook.com> (raw)
In-Reply-To: <AM0PR01MB5634012E7A37C8D806933665DD0D9@AM0PR01MB5634.eurprd01.prod.exchangelabs.com>
References: <[email protected]>
<AM0PR01MB5634012E7A37C8D806933665DD0D9@AM0PR01MB5634.eurprd01.prod.exchangelabs.com>
I believe the point is that the function is a "W" (wide char 16-bit) function so the strings should be UTF-16.
Jon
________________________________
From: Wal, Jan Tjalling van der <[email protected]>
Sent: Tuesday, November 22, 2022 11:21:56 AM
To: Marsupilami79 <[email protected]>; [email protected] <[email protected]>
Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count?
Hello Marsupilami79, Jan,
It could be that the answers you receive are in fact correct for postgres.
In a database set to charset=UTF-8 I get the following answers.
select 'topsales' as string, char_length('topsales'), length('topsales'), octet_length('topsales');
"string" "char_length" "length" "octet_length"
"topsales" 8 8 8
However for a variation that requires more bytes to store the answer start to differ.
select 'töpsålés'as string, char_length('töpsålés'), length('töpsålés'), octet_length('töpsålés');
"string" "char_length" "length" "octet_length"
"töpsålés" 8 8 11
In the above octet_length is a postgres-function that yields results in bytes.
And the three characters with a diacritical added, each requires 2 bytes, yielding a resulting lengt of 11 instead of 8.
Kind regards, Jan Tjalling van der Wal
-----Original Message-----
From: Marsupilami79 <[email protected]>
Sent: 22 November 2022 16:57
To: [email protected]
Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count?
Hello,
I am a co author of a data access library and we recently added an ODBC bridge. This bridge has the capability to detemine the current Catalog / Database. This is done by calling SQLGetConnectAttrW.
We try to determine the size of the buffer that is needed for the catalog name in the following manner:
SQLGetConnectAttrW(fHDBC, SQL_ATTR_CURRENT_CATALOG, null, 0, &aLen)
The ODBC driver for Microsoft SQL server correctly returns the number of bytes required (10 bytes for the Database name "Stork") in the aLen parameter. The ODBC driver for PostgreSQL returns the number of characters (8 characters for a database named "topsales"), where it should return 16 for the number of bytes required.
I tested this with the psqlodbc_13_02_0000-x86 download for Windows 10 and installed the Unicode ODBC driver.
I assume this is a bug and needs to be fixed. I just don't know if this is the right place to report the bug to?
With best regards,
Jan
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count?
In-Reply-To: <SA1PR17MB5350D74A659E421C12CA9125BE0E9@SA1PR17MB5350.namprd17.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox