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 1p0L8Q-0000hU-1I for pgsql-odbc@arkaria.postgresql.org; Wed, 30 Nov 2022 11:20:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0L8O-00051b-OS for pgsql-odbc@arkaria.postgresql.org; Wed, 30 Nov 2022 11:20:12 +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 1p0L8O-0004zN-FD for pgsql-odbc@lists.postgresql.org; Wed, 30 Nov 2022 11:20:12 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p0L8I-0007EC-LA for pgsql-odbc@lists.postgresql.org; Wed, 30 Nov 2022 11:20:12 +0000 Received: by mail-ej1-x62f.google.com with SMTP id e27so40510937ejc.12 for ; Wed, 30 Nov 2022 03:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=urntqzLMRYXvnFX9+kXvdwHOE0oI+evfMlLPCnACDwE=; b=Mv30xEQ0MhUQ6w3ss0fqf9JFEy3TB0ZNw3SZ5Ziv3wd6ooBT1lD+eIBTuVmEKseOnr CBgnOPoZxfAfpFFcXrhiQeOchsRJc3G2hNSIwDFviFSxstlmVeM4fxPEeVni+zPxRscD DXrl5LwgoX3xxpureLtlKs2FEID1ibnltQwLRdrtVQk9+HYvIjh685zyrPe1LTe57wBd 8Yf8w/4XBiIjg8Oa3xld7uQdnin+B4cFfRaY7RU6d0o+Qs9KzzrS5GG72+pQXVlHTURw tL5eiH9V7jgF0oSYivKN2aaQxJXTbhF7q7j174GxeWNPIRyIASrpVNSgHkWfNi0s8CFg MeMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=urntqzLMRYXvnFX9+kXvdwHOE0oI+evfMlLPCnACDwE=; b=DN236H1j1JyW/RPnDXnjkeZPfIQ/DVBRhDh4fZEFF/PW/iU25O6Ap+CoBxD+Ea9qFp 6ZfxTted4CHX9qBkNomt02oIMH2xGQBMr78K6zR98kZUKZTXi5VH8jzVk8En8+JCMMEZ eN7xuI916uhAOd0pkIxINbk4d11C2Ex1Q0dySl+dZdarksmV4tVxo0fDnzPsAGSKr3qw /djrS1hDtJLpT6Jw5at9E8TWghRIsIApEpiYQNjyib0XhOJkYiFipvP9zt4ptYBWasAX WGS7uAQNaUP+uIHH8ppGBgxf9HKG5BRDYZUyvaLLI0ZWyxP4ezxR+zAsbiic7ZYUjVSl Yfcw== X-Gm-Message-State: ANoB5pmyTPrAo2mtwsiMptb1R3dAAbQYA8aXbsf4kOctYGVWxUq/EwV1 LHmNQfJTcDvtIQH9iQ5iOUn1W79tNWIvtrc86DWvBauc X-Google-Smtp-Source: AA0mqf4jMMl3HZIfsdfb+kE0ewnmoRmsQF6/wMxAhXinGJ5DfZoiNGn20zgZ8vfxj8Peofa2LfrfvJN98C5Z1P6gUfs= X-Received: by 2002:a17:907:1387:b0:7bd:b901:4b86 with SMTP id vs7-20020a170907138700b007bdb9014b86mr17730460ejb.712.1669807205541; Wed, 30 Nov 2022 03:20:05 -0800 (PST) MIME-Version: 1.0 References: <39e35073-0cac-5d64-9a72-b47ea671fb20@gmx.de> In-Reply-To: <39e35073-0cac-5d64-9a72-b47ea671fb20@gmx.de> From: "Inoue,Hiroshi" Date: Wed, 30 Nov 2022 20:19:52 +0900 Message-ID: Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG => wrong byte count? To: Marsupilami79 Cc: pgsql-odbc@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000546bc705eeae4906" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000546bc705eeae4906 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, The psqlodbc unicode driver correctly returns the number of bytes(10 bytes for a database name "visco") here. regards, Hiroshi Inoue 2022=E5=B9=B411=E6=9C=8823=E6=97=A5(=E6=B0=B4) 0:57 Marsupilami79 : > 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 > > > --000000000000546bc705eeae4906 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,

<= div>The=C2=A0psqlodbc unicode driver correctly returns the number of bytes(= 10 bytes for a database name "visco")=C2=A0 here.

<= /div>
regards,
Hiroshi Inoue

2022=E5=B9=B411=E6=9C=8823=E6=97= =A5(=E6=B0=B4) 0:57 Marsupilami79 <marsupilami79@gmx.de>:
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 aL= en
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


--000000000000546bc705eeae4906--