Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyOvI-0001by-2e for pgsql-odbc@arkaria.postgresql.org; Fri, 25 Nov 2022 02:58:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oyOvG-0003KW-W4 for pgsql-odbc@arkaria.postgresql.org; Fri, 25 Nov 2022 02:58:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyOvG-0003KM-Jn for pgsql-odbc@lists.postgresql.org; Fri, 25 Nov 2022 02:58:38 +0000 Received: from us-smtp-delivery-114.mimecast.com ([170.10.133.114]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oyOvC-0007ic-O3 for pgsql-odbc@lists.postgresql.org; Fri, 25 Nov 2022 02:58:37 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2042.outbound.protection.outlook.com [104.47.57.42]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-288-3vu9LBdYMMq9B8N9eEv-ww-1; Thu, 24 Nov 2022 21:58:30 -0500 X-MC-Unique: 3vu9LBdYMMq9B8N9eEv-ww-1 Received: from SA1PR17MB5350.namprd17.prod.outlook.com (2603:10b6:806:1d7::17) by MW5PR17MB6009.namprd17.prod.outlook.com (2603:10b6:303:1a9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.18; Fri, 25 Nov 2022 02:58:26 +0000 Received: from SA1PR17MB5350.namprd17.prod.outlook.com ([fe80::19ea:35c9:8416:28ca]) by SA1PR17MB5350.namprd17.prod.outlook.com ([fe80::19ea:35c9:8416:28ca%7]) with mapi id 15.20.5834.015; Fri, 25 Nov 2022 02:58:25 +0000 From: Jon Raiford To: "Wal, Jan Tjalling van der" , Marsupilami79 , "pgsql-odbc@lists.postgresql.org" Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? Thread-Topic: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? Thread-Index: AQHY/oxlHs8GytInmkWUfMw/cvk+Ea5LH/sAgAPEqbk= Date: Fri, 25 Nov 2022 02:58:25 +0000 Message-ID: References: <39e35073-0cac-5d64-9a72-b47ea671fb20@gmx.de> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA1PR17MB5350:EE_|MW5PR17MB6009:EE_ x-ms-office365-filtering-correlation-id: 7c9bf344-8cda-4912-3edf-08dace90ec24 x-ms-exchange-atpmessageproperties: SA x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: Ukw6qqh6GnLO8JqLsq6CH60kQhklRayTe0CTY1ZCh+6RbqBsBO6ZnOmnckoI6yDwNcrmfiqkBvrYj9yE8OD3qNZYC6CCn0UL+kQ98RycYtJGb9xUrCZ40/vymN2kD5uhTjxn6YJmwqmvUrEfCyTH90ZAAjBHgrRUs3Ot2b3nggDDwfI1ohrDFdW3LiUEFmtYnt2GSkn92RatJNwA9/riNwjxkM/I2PeuklevNcVp/kcQyoXRoLV1cOg+AKI14FiNeQPuPg8Ba46+Vhbvv/Z0LQrrx4vrcvOPFsU/tv9fbo4MDOqok0A0JqR8/dxtxjo+XM1r+B4FCGrQwdDM9t1v73uZF9dbddzaNF9iW8IrtIlJOee0MhXd/eeE4WcF0FvjibX+Oj/hnhYI2K1oSDr3ORS32ApjCubGDdIJX+t6Rs/0y3usQPq74sPQWxaCQT25pgCbgIt9Nt+z7ZBe45f3Tz/wJaG7raelLfdTaSGe+G5W9iehcJ+ELpMtaYmvlg28/T4mkK/NKPsgqnG5GTPOyQAGdGWO4Fl+NWilUgq9//ud9JanAJLRTHoSWf6rkGn58rne6l5WiY95peODkecPNd14nh6OOSVJDCx4tvvF7xZulnVqDnNtNzv1oA/yikrwpMvozIP+g9siSijfffA8Sx5Ck+N8Wxo2lU1EB5w+0T+YDiHr/zGiRfDch657nKAiZN8WSU4aN4EkAO76pVGR/g== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR17MB5350.namprd17.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(346002)(39850400004)(376002)(136003)(366004)(396003)(451199015)(8936002)(2906002)(41300700001)(52536014)(186003)(53546011)(7696005)(6506007)(110136005)(66556008)(316002)(66946007)(76116006)(91956017)(66476007)(66446008)(9686003)(8676002)(64756008)(26005)(55016003)(38100700002)(86362001)(122000001)(38070700005)(66574015)(33656002)(5660300002)(83380400001)(71200400001)(45080400002)(478600001);DIR:OUT;SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?k4rREk5rH52LY77uCg68bE8eMvyRMbikqcCg/gZHEU+80vxbCtYDLYjJWQ?= =?iso-8859-1?Q?ZD4pOiWimQF0VYAwEPP6dEcjAO7jjKxdzbNnr4zOQrsL5JKb0ZhF+OdFCI?= =?iso-8859-1?Q?p06AxCSfmqKH8BoPUrJ6ZnitHsAtRkkG/AJgBY0+dUVetwX9jac4PUSgsy?= =?iso-8859-1?Q?83f8K+tiU3//FB/7WnABjI/gOTe4xLgwNoUKmiByOntqKShq6s5WvQspyX?= =?iso-8859-1?Q?LULkA6D2ahGoi2l0AS3TwoKxNQHzS/3hUNZ1D626Lyg7DMAKNd/fpJNZyY?= =?iso-8859-1?Q?yULHUqkxloUsWfGvtPyJvUwoAi6nMZhCk1hKdmVGtv4YQe8eJM3LJujkFW?= =?iso-8859-1?Q?bhsjj1RNQ/g+PaEsnbqYf9igQPHcu45vs7Bfhq2pEBmsU94Ttg8KqBx2iL?= =?iso-8859-1?Q?iVyBZvsaBvJTMz6zK0Lo1kycWc+M2r8/71sa8ip0lAxIrniQnuK4QTwmMa?= =?iso-8859-1?Q?fUWmgf2VbVBtPxTtl5Yw+7+JuHcwrKCrIP5nk3d2MPWKIfrGjL7VM2mYmX?= =?iso-8859-1?Q?kYAzdd2R0NtxoK4b6d6G1uFo1NGXtIiFYdyW06VEnVqX9dgwFLSiyHtPnp?= =?iso-8859-1?Q?RvhDvGGguV/DlmCQojenHKyjNGjt994yZrJP0SISvP0GmolZkct5oARN3y?= =?iso-8859-1?Q?U2giLGXf21ATyY/T7y/qfxcr+xFeh55uqtyVh/y55CSN2JnWTr+xf77cHT?= =?iso-8859-1?Q?j92hJdA5X0m71ZVcAPLcPbv8QvTKXibbstEgQTtGYazWHwDifTKXzM/2yU?= =?iso-8859-1?Q?mZWo1MgtSku1H3Xc0bHkDq5iZSO6EwxlOpPTjNpR0kVZuQH3zZ6jSEXvTJ?= =?iso-8859-1?Q?/Rbg+0YvG3wInC1BdDwfaYs4ovloLY9klG8E5x4OyiUy1a1Aroc3vF5f7B?= =?iso-8859-1?Q?vAnlc5r3GCIrkFU1KCG3LJlPogsnOTB5CI6LplPz+9LEiypRpfLODS291o?= =?iso-8859-1?Q?mGL8zXHHNPDIklQixLrrCBeGr8E88uSokQVsNwcuCBGkfOUqZgKVHIhb5z?= =?iso-8859-1?Q?Sua/r282OCUvWhCO1m37xERbJ5LbRmpuzwuSf/e+YYW7DJ/MrBIIONRlNR?= =?iso-8859-1?Q?yazMbHEFLn8r5hrtKZrXtUFWw7hZTi2QBxH3KwSrI7zk1cIHyPQYRH626H?= =?iso-8859-1?Q?PiEGGtVsi7zTWdRbeg285zjsY9+d90C3ubqLxK5819cks0D+bTR/PMGutB?= =?iso-8859-1?Q?A5OrveNIHx4gBOx2Kvx9pPVk0CiyPvc3SF6h9BX4E0YDSWc28QvJK/byBK?= =?iso-8859-1?Q?TFk3+Ayh0TyC3rEPCh3A+H/NiE/OPO0GjeUjDs9o5JX3wG5KZfn6VvWyGM?= =?iso-8859-1?Q?HY+nCIe/2ia13g8U5nUTKd1VT6I0Gz6liaXcZLDxG/rT6Wz63SvifLilEn?= =?iso-8859-1?Q?A2qMI2R6cZWKERE7A8oiwyjN97Kq5AXsDi9L641370q6xM5TQBPyd8IMJ3?= =?iso-8859-1?Q?ZgeG12iuogiTUjkVWrPw0PBw4hY0S9mGVIK1KXDcmtiu5+bcRsdC168cER?= =?iso-8859-1?Q?HH6G1mdMBRcEYTaVsXQ7vPrzVcO8L8T02nv5BNMr5Or7CdMEGiGfg5LVJ8?= =?iso-8859-1?Q?L/npK0jnyklJk9GRxcYeymLF+7AQyWNsiO5GIC/wehDNbJOOveVO90felR?= =?iso-8859-1?Q?6Q9r8sC7Deh1PWRKhS4GYmmVu8WOij/3wO1tbuJ6DXXW60PkQyaZdU4w?= =?iso-8859-1?Q?=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: labware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR17MB5350.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c9bf344-8cda-4912-3edf-08dace90ec24 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2022 02:58:25.8132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b5db0322-1aa0-4c0a-859c-ad0f96966f4c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n0w9Wxns/Z214sCArOYf4odP8lZTRpWVNjBWDXv+R8o/3Ucgzl3OInNXPEsUji33gnTtiLJ5LeOnE0dR51olNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR17MB6009 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: labware.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SA1PR17MB5350D74A659E421C12CA9125BE0E9SA1PR17MB5350namp_" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_SA1PR17MB5350D74A659E421C12CA9125BE0E9SA1PR17MB5350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I believe the point is that the function is a "W" (wide char 16-bit) functi= on so the strings should be UTF-16. Jon ________________________________ From: Wal, Jan Tjalling van der Sent: Tuesday, November 22, 2022 11:21:56 AM To: Marsupilami79 ; pgsql-odbc@lists.postgresql.org <= pgsql-odbc@lists.postgresql.org> Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> 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=3DUTF-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=F6ps=E5l=E9s'as string, char_length('t=F6ps=E5l=E9s'), length('t= =F6ps=E5l=E9s'), octet_length('t=F6ps=E5l=E9s'); "string" "char_length" "length" "octet_length" "t=F6ps=E5l=E9s" 8 8 11 In the above octet_length is a postgres-function that yields results in byt= es. And the three characters with a diacritical added, each requires 2 bytes, y= ielding a resulting lengt of 11 instead of 8. Kind regards, Jan Tjalling van der Wal -----Original Message----- From: Marsupilami79 Sent: 22 November 2022 16:57 To: pgsql-odbc@lists.postgresql.org Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte coun= t? Hello, I am a co author of a data access library and we recently added an ODBC bri= dge. This bridge has the capability to detemine the current Catalog / Datab= ase. This is done by calling SQLGetConnectAttrW. We try to determine the size of the buffer that is needed for the catalog n= ame 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 by= tes required (10 bytes for the Database name "Stork") in the aLen parameter= . The ODBC driver for PostgreSQL returns the number of characters (8 charac= ters for a database named "topsales"), where it should return 16 for the nu= mber 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 --_000_SA1PR17MB5350D74A659E421C12CA9125BE0E9SA1PR17MB5350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
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 <jan_tjalling.vanderwal@wur.nl>
Sent: Tuesday, November 22, 2022 11:21:56 AM
To: Marsupilami79 <marsupilami79@gmx.de>; pgsql-odbc@lists.pos= tgresql.org <pgsql-odbc@lists.postgresql.org>
Subject: RE: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> w= rong byte count?
 
Hello Marsupilami79, Jan,

It could be that the answers you receive are in fact correct for postgres.<= br> In a database set to charset=3DUTF-8 I get the following answers.

select  'topsales' as string, char_length('topsales'), length('topsale= s'), octet_length('topsales');
"string"         &nb= sp;      "char_length"   "= ;length"        "octet_length&= quot;
"topsales"      8    = ;           8  =              8<= br>
However for a variation that requires more bytes to store the answer start = to differ.
select  't=F6ps=E5l=E9s'as string, char_length('t=F6ps=E5l=E9s'), leng= th('t=F6ps=E5l=E9s'), octet_length('t=F6ps=E5l=E9s');
"string"         &nb= sp;      "char_length"   "= ;length"        "octet_length&= quot;
"t=F6ps=E5l=E9s"      8   = ;            8 =             &nb= sp; 11

In the above octet_length is a postgres-function that yields results in byt= es.
And the three characters with a diacritical added, each requires 2 bytes, y= ielding a resulting lengt of 11 instead of 8.

Kind regards, Jan Tjalling van der Wal


-----Original Message-----
From: Marsupilami79 <marsupilami79@gmx.de>
Sent: 22 November 2022 16:57
To: pgsql-odbc@lists.postgresql.org
Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte c= ount?

Hello,

I am a co author of a data access library and we recently added an ODBC bri= dge. This bridge has the capability to detemine the current Catalog / Datab= ase. This is done by calling SQLGetConnectAttrW.

We try to determine the size of the buffer that is needed for the catalog n= ame 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 by= tes 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


--_000_SA1PR17MB5350D74A659E421C12CA9125BE0E9SA1PR17MB5350namp_--