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 1oxVdy-0006YZ-70 for pgsql-odbc@arkaria.postgresql.org; Tue, 22 Nov 2022 15:57:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oxVdx-0007mp-35 for pgsql-odbc@arkaria.postgresql.org; Tue, 22 Nov 2022 15:57:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxVdw-0007me-RF for pgsql-odbc@lists.postgresql.org; Tue, 22 Nov 2022 15:57:04 +0000 Received: from mout.gmx.net ([212.227.17.22]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxVdu-0003iy-N2 for pgsql-odbc@lists.postgresql.org; Tue, 22 Nov 2022 15:57:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1669132621; bh=I44Cw1s5oK7g2V21tb0EnRDP1HfqBAV/sRnT8i2P31k=; h=X-UI-Sender-Class:Date:To:From:Subject; b=HNQYmBs84GwB3S/5gMtsdGmw03D7bJIesx7dmCviAX5/nB5prk1L0xnEZMtDUHiSW xpaCN7IG+Xipl0pkCrOchbglLNrM6qsuDcoR0Nx317DVu2uUQvU1F5rtaXbk1zTuPW AOd378hbXHuUwB/yuuaC8fb/f4334r37RW7kt9kdUHAiCgUkIWnSE7fhkeEzaDGeKC c3Xkf8ZaPOPB8b0OKabRh9FsIfNQDDzSRcyzAG4C6nb+t/xtPeS6MZLSKNkxCchBoC tADew95xgrxTpF2hhBObpw5Wi4Bn7WmUfKpEqDD41ajINOstXLhPPev2/JUshLVCld V4MRz6ClaZDBA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.72] ([178.13.20.97]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MVeI8-1oVucC36l2-00Ra0r for ; Tue, 22 Nov 2022 16:57:01 +0100 Message-ID: <39e35073-0cac-5d64-9a72-b47ea671fb20@gmx.de> Date: Tue, 22 Nov 2022 16:56:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: de-DE To: pgsql-odbc@lists.postgresql.org From: Marsupilami79 Subject: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:emzkH7lw+FBbxt4b2NlYQ9j8uylqkdAc13jk3hHMQS0r2sYcF5v MXQU80nIYsqX8hgZormQmtEOjCfWHdGVvcfulYFTVj/2zJw8C9rc2HMfnBClXFGU4siwTFB RtWucEsz3nvCTo2s6jClPy7J8oy0LNWYoMss5CM33LfgIItEWFu9++rH3FATFpfpCEBsuqA greb9SnSYhprWbpVTAMag== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:WND0HUbZXgk=;81LIvF+iWdmeDKy2xDzVoz8OXmO m4XKSCS7J8Hr8h6BNjtpeoSIDGupNwCP5R3txmuEzm1nytVowY54ZNu3scclof4pHfAUfwX/h hX4cacjXsBkYLCTKCy8dz5YiXUlta1IJTMdEHxTYPqXMXccTm4K1JXUHnhQmgqv8ojSQfAmzE 51misbZ38dhj42iCCzJzUiy/WQCGLQ3vMLeg+Pn/xIY4but+EqDcbh8pKUkwNHxnjm1eMn1On 3UIyfmMaMx4LGSMPkLzkrx2G6SIw7mzgnlkcHPBWR6VVoGHFx+6NzYklgygKvb5kPvcQ865jw DwD1p+1/BjUjj9iMAL3K+2qIR+ZS+QPoAutZ4BPwYpv5kj29KGFct+9ycgtVnTDjkjFr2sMmR S2jAIbQi1TSf91bJRZNTW28k4KqehLRu/TpX6504qank7JQ9GPYo6N+qwak+izlBAJj4U0RKr n/YkX1vFA/oNEwedIvl8jaDnnAhDQCysN5aTvhkFlyTgFkSRDDSyCrr/pmdnloA2p4nhuOx7n YHzOilwR/mbXDSrBEO7hN8p/AIH75xy7ETEjP02lS3gxvAy1Rdu0J55chz9fMQqSQahz3U794 X+OzBXwkHIOUCjtPCHdEd9Moetwa/5+uxV9JgUwEOkVkEyW+Nr2qeRbqSka1wkT/u2JNnHc6c oxn0t++ZIwkEqJEtFMMLQSc+FYxlPFPFrgYa/CVxhMdCXkpxIsE/DaOIzkBNa2Nb5X6+AiVaM ZNu13vyulwYWx7cTgVuPejYuAMfF10CYyQplDo3kf16riWGLzO7BaDrIROSfG3cm4ayGp34cq Il5K1e1rd4nzlj5+4tg89k7zB7whhngpgwQbE1RI5RIR8ZTrYQwA25vYeHNmEZM7tYhM2/C1J 9F5fiDBRa5HYAW5Hzhp3ADCQp4CpGDs2EAddXFnZuk3C0s0zruaKB1PaTHy7HiftV7dPNQWby +AasAw== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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