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 1ozehy-00082q-RQ for pgsql-odbc@arkaria.postgresql.org; Mon, 28 Nov 2022 14:02:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozehx-0006S8-NL for pgsql-odbc@arkaria.postgresql.org; Mon, 28 Nov 2022 14:02:05 +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 1ozehx-0006Rz-77 for pgsql-odbc@lists.postgresql.org; Mon, 28 Nov 2022 14:02:05 +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 1ozeht-00082e-Sg for pgsql-odbc@lists.postgresql.org; Mon, 28 Nov 2022 14:02:04 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-458-ebabTNz4OfiZYsD0tiJTfw-1; Mon, 28 Nov 2022 09:01:58 -0500 X-MC-Unique: ebabTNz4OfiZYsD0tiJTfw-1 Received: from SA1PR17MB5350.namprd17.prod.outlook.com (2603:10b6:806:1d7::17) by MW4PR17MB4466.namprd17.prod.outlook.com (2603:10b6:303:7a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.20; Mon, 28 Nov 2022 14:01:54 +0000 Received: from SA1PR17MB5350.namprd17.prod.outlook.com ([fe80::19ea:35c9:8416:28ca]) by SA1PR17MB5350.namprd17.prod.outlook.com ([fe80::19ea:35c9:8416:28ca%8]) with mapi id 15.20.5857.023; Mon, 28 Nov 2022 14:01:54 +0000 From: Jon Raiford To: Marsupilami79 , "Wal, Jan Tjalling van der" , "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/sAgAPEqbmAASTeAIAEL0KAgAArpcQ= Date: Mon, 28 Nov 2022 14:01:54 +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_|MW4PR17MB4466:EE_ x-ms-office365-filtering-correlation-id: 4114548b-f87f-4b3a-991b-08dad1491af4 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: IyApMuoHNrV94YHYzye/z/8KZVXohYaQxoK2ZQguCGqbyTvFTX96MTV0RQ84spwVvDXzg9bZmTBalGD8S7i/2dZgS3skknrB3z5rjWMBuZLPdKG1f/jsgXEKVsTsfCKu3h1fEUiLhO3FoF5EYdpaMxovUNivUpGSw1CaaRuyKiMBVTMFTqy+VWGkPCMDYZ9Eo9YpgT2zgELKF+/wFlAgqnm3bHYAqA9UFBFXp3sYrEPWTriJwK/etEl94gc+2h3NGHdCYiH8Xx//LsnjGb/EwdDYB+KaIZf2gw954uy7HAltE226BOTkjs36tiYX9s7j6X6Uvj2t6e76xY4SW/CxbnMOUGFOvcTdHhYXtZtP9zH+4lqwGDdT6n3NeHLs1cNk0gk1aNZAS1LgH3JuB/wkDw5tNV02P3oOZRxaYCEO51yTBsn0pBXzu2bQZ2dc05x1I1gxKR0R3jFuz3tt3gqrprTBH1eO2GFFuv3DZDhHzrFBpTCUEyGp5JKw1ayHdIe02NeEGPLQ0ZHDdtMR1G2T1K1gSfPHO42aytymDotW+DeRlUMOv+nzs5a4HASD+JbVsPXTqbhcNj3IbJolnq6r1alOGO786H3KBXJ6ENRbiVHx1rAFIhv3Jietv9HknKTHXq9IekuZAkq9OPkxAfmrszWDOef1WBWmMurSVHmPHtNyMjasbqfmXC1VH3P1GtAu7GnMG4c8y+WQd28/34Fb+7AAVxZWmC+uvCpzCBQOckYXC5ngdHb22KrPxwK3I/H0Qt1n6iRJeFEyXOETuAU6YQ== 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)(136003)(346002)(39850400004)(366004)(396003)(376002)(451199015)(166002)(53546011)(45080400002)(71200400001)(26005)(122000001)(478600001)(9686003)(38100700002)(966005)(7696005)(6506007)(41300700001)(76116006)(66946007)(64756008)(66476007)(66556008)(8676002)(66446008)(91956017)(33656002)(86362001)(38070700005)(52536014)(316002)(55016003)(110136005)(5660300002)(8936002)(186003)(66574015)(83380400001)(2906002);DIR:OUT;SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?mxDWkIA4xUXVri8E58pT5gH86/Q8pTZBXSRTnB8L35hp9yPK2JzHtAce?= =?Windows-1252?Q?JbRpnODUPWFVLdwSo0N4QHBGOkgHm2u5ePQbp53w4w2BBooCaImSGcma?= =?Windows-1252?Q?yUnDZnC0xCqyNuDq863QXSqWG4aztE5sDxA2SETNsoZqvaD+VXVw9jTM?= =?Windows-1252?Q?P0HEggVj0sJe4NXBD/LlZhENvLaj696TZfdy7ICLUtGj7PC1zrCcM5zT?= =?Windows-1252?Q?XCtX44AB9II7miBa5QFVJGb1Elleyt/Ognfq6Tip9zkZBeagvVTxdiwm?= =?Windows-1252?Q?6QUOYm5jpYvhomD+lVpITMc6zTyuMM7eCC20W2yCfL8zrLpDjUw1HRRT?= =?Windows-1252?Q?A06lrLB8fYr3Cxoq/w3yTHHiQ/ZN0u2Aj8dGSpProBQAow9G4l+hd7xO?= =?Windows-1252?Q?ppwfg4kb2UVzhXrF4j3YJdl26BlHoPsxOrVD/TvNwHZUmP1tM9Oc+Rrk?= =?Windows-1252?Q?T/BOXskaICv2Klysx3TBtuJho4k0W6I0gBJnWYnGUfErqVBeU3+yEHrZ?= =?Windows-1252?Q?NjUcTKxy0pR6g8jomY97s4IVecUX56pMXYK+OAOa+Cofmkj2y7nvOxQj?= =?Windows-1252?Q?FtX5fGU5toGJh58A9b8eMm5UKXpVIAThzneDEOc56iZ5otZ0dffFU9++?= =?Windows-1252?Q?Zx1UXUUwhR1B5lHQ/0C3SmqI/lzj3ZkJ1/C74LV+k3FI9E0X1cOkvFKY?= =?Windows-1252?Q?tAqKRDM0SXej1x9ikAff6gBL8kRgT0s9IAPWh43vKrpvf0RIX10x7GLP?= =?Windows-1252?Q?g7elVJ8jtypUHLpAmypNUFQtdpDanaRyQRqv8FsQoKad5Z/JN/3BdtQH?= =?Windows-1252?Q?jlAahBj/K/AfP9i/FjYM8upPMbhnO/IQPyaneb/LUhw4AGa+uN/Ebm/Z?= =?Windows-1252?Q?3ejOqRPgDWzKq7d0F66W9ZmZrW9O7V7T7h19lB9VuO8CPGbT8lrlhOW6?= =?Windows-1252?Q?CW8hELvyx0ZPejZk9h9DQmjb4XIErWW32jSB9y7DXYdG14LuEVqWIcem?= =?Windows-1252?Q?igj38kCbea0EFANNej6eXm51RFJuKAGOFJQT1ZnaTDO4GV1i+hfYj4VH?= =?Windows-1252?Q?f6PVkSBFDSAdN6tPEWa3z6rDSXVcHhUyVPSGnbHCXcLvNtT+yVHEZTzX?= =?Windows-1252?Q?QjYrV0oU+1rsL6TRVMpDE+De5sDLNGFwpVoH0Td9MZ0AosU4MIwmqts0?= =?Windows-1252?Q?DaZC6cT7XiWcCnpBkwrbO252i9WTkS4NHIxO9qr0lC4+TaM/TpJiXrjp?= =?Windows-1252?Q?TSpSCp9emTbt3Kb1tXtCm9NtJ9y1+xFoR6faeQjvMjy0HX4Uk22Jmnow?= =?Windows-1252?Q?7zApRSjRGe5s/1dtC9DtOpKQkZwlRpZxWzUp59TyahYgl09Mp27UiFuf?= =?Windows-1252?Q?rmbmgMDLzrJ7YDceHMXFhNQrE6EvKNQmUzgbX+zY8tSbwXNxE7+IJprb?= =?Windows-1252?Q?h91o1b6po258vUtFS6KyGY6QJvOofOeAhAycKZjqKk9DRvaiCIdnrNhz?= =?Windows-1252?Q?RBx+YDLxmQnGHDT6B5r2R0t0Y/R+4a24T4MVW2MwGQlwUVbivIj1+uWu?= =?Windows-1252?Q?x9G1dT3brTmfHJ+0i8ii+Cx9AaWvooolG106LAPJseDrzV8PGB7uhqB/?= =?Windows-1252?Q?GkvdX0KKh20H61zBhJ7AriXwP0X+hAyeMOYf4f+/nO3dn1nhUMtGsRpc?= =?Windows-1252?Q?D2m6d0Ugjjsnt3i9OhwN6JWlxnCtuKtjtwtH5G/bgde1GBdme+5l3A?= =?Windows-1252?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: 4114548b-f87f-4b3a-991b-08dad1491af4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2022 14:01:54.0933 (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: dj8AIH/awa2r4Ct7F2fpXiitAM8bJeYJumsKL20NY6JjBxNJ8Qg+gTXiStlj1Fpsa2SU7FE5AoXIJ5FVOic4qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR17MB4466 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: labware.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SA1PR17MB53505D184D6E51B93F7F94A2BE139SA1PR17MB5350namp_" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_SA1PR17MB53505D184D6E51B93F7F94A2BE139SA1PR17MB5350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I don=92t know if there is an official place to file a bug report for this = issue. I have seen several issues reported in this email list which were l= ater fixed, so presumably this is an appropriate place to document the issu= e. I did some research on this and found something interesting that may help. = If you look at the documentation for SQLGetConnectAttr() from Microsoft, t= hey specifically mention the wide char format: https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetconnectat= tr-function Under the description for the BufferLength argument (describing the length = of the buffer used to answer the attribute value): =93If the value in *ValuePtr is a Unicode string (when calling SQLGetConnec= tAttrW), the BufferLength argument must be an even number.=94 The reason this is expected to be an even number is because all Unicode str= ings use 16-bit characters in Win32 wide char functions. I hope this helps, Jon From: Marsupilami79 Date: Monday, November 28, 2022 at 6:22 AM To: Wal, Jan Tjalling van der , Jon Raiford = , pgsql-odbc@lists.postgresql.org Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte = count? Hello Jan Tjalling, hello Jon, Jon is right - SQLGetConnectAttrW is a WideChar function (2 Bytes per Chara= cter). So the encoding in the PG database should not matter. It should retu= rn the length for the SQL_ATTR_CURRENT_CATALOG attribute in bytes. So for a= database named "topsales" it should return 16 because each character uses = two bytes. I assume this is a bug in the PostgreSQL ODBC driver. The question is where= to file a bug report and how to get this fixed? Is there a chance to get t= his fixed? With best regards, Jan Baumgarten Am 25.11.2022 um 20:22 schrieb Wal, Jan Tjalling van der: Okay, getting out of my comfort zone here. I have found encoding options for PostgreSQL (v15) here: PostgreSQL: Documentation: 15: 24.3. Character Set Support; t= hey do not include UTF16, just UTF8. There is no mention of UTF16 anywhere on that page. I also found this: PostgreSQL: Re: DataDirect Driver, ExecDirect and UTF-8<= https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fprotect= -us.mimecast.com%2Fs%2FAAWRC2kw4vUgmQJc1gEOy%3Fdomain%3Dpostgresql.org&data= =3D05%7C01%7Craiford%40labware.com%7C050b022beed84021061f08dad132d1e5%7Cb5d= b03221aa04c0a859cad0f96966f4c%7C0%7C0%7C638052313459015632%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C3000%7C%7C%7C&sdata=3D0SfOO6NczbbCACRcxjoKxeHLmq%2BVLtJJjedWxGyKr7w%3D&re= served=3D0> that does mention WCHAR being different form CHAR and how that = could work. I hope there is something on these pages that helps you further. Kind regards, Jan Tjalling From: Jon Raiford Sent: 25 November 2022 03:58 To: Wal, Jan Tjalling van der ; Marsupilami79 ; pgsql-odbc@lists.postgresql.org Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> wrong byte = count? 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 >; pgsq= l-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_SA1PR17MB53505D184D6E51B93F7F94A2BE139SA1PR17MB5350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I don=92t know if there is an official place to file= a bug report for this issue.  I have seen several issues reported in = this email list which were later fixed, so presumably this is an appropriat= e place to document the issue.

 

I did some research on this and found something inte= resting that may help.  If you look at the documentation for SQLGetCon= nectAttr() from Microsoft, they specifically mention the wide char format:<= o:p>

 

https://learn.microsoft.com/= en-us/sql/odbc/reference/syntax/sqlgetconnectattr-function

 

Under the description for the BufferLength argument = (describing the length of the buffer used to answer the attribute value):

=93If the value in *ValuePtr is a U= nicode string (when calling SQLGetConnectAttrW), the Bu= fferLength argument must be an even number.=94

 

The reason this is expected to be an even number is = because all Unicode strings use 16-bit characters in Win32 wide char functi= ons.

 

I hope this helps,

 

Jon

 

From: Marsupilami79 <m= arsupilami79@gmx.de>
Date: Monday, November 28, 2022 at 6:22 AM
To: Wal, Jan Tjalling van der <jan_tjalling.vanderwal@wur.nl>,= Jon Raiford <raiford@labware.com>, pgsql-odbc@lists.postgresql.org &= lt;pgsql-odbc@lists.postgresql.org>
Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> w= rong byte count?

Hello Jan Tjalling, h= ello Jon,

Jon is right - SQLGetConnectAttrW is a WideChar function (2 Bytes per Chara= cter). So the encoding in the PG database should not matter. It should retu= rn the length for the SQL_ATTR_CURRENT_CATALOG attribute in bytes. So for a= database named "topsales" it should return 16 because each character uses two bytes.

I assume this is a bug in the PostgreSQL ODBC driver. The question is where= to file a bug report and how to get this fixed? Is there a chance to get t= his fixed?

With best regards,

Jan Baumgarten

Am 25.11.2022 um 20:22 schrieb Wal, Jan Tjalling van= der:

Okay, getting out of my comfort zone = here.

I have found encoding options for Pos= tgreSQL (v15) here:

PostgreSQL: Documentation: 15: 24.3. Character Set Support; they do not include UTF16, just UTF8.

There is no mention of UTF16 anywhere= on that page.

 

I also found this: PostgreSQL: Re: DataDirect Driver, ExecDirect and UTF-8 that does mention WCHAR being different form CHAR and how that could work.<= /span>

 

I hope there is something on these pa= ges that helps you further.

 

Kind regards, Jan Tjalling

 

From: Jon Raiford <raiford@labware.com>
Sent: 25 November 2022 03:58
To: Wal, Jan Tjalling van der <jan_tjalling.vanderwal@wur.nl>; Marsupilami79 <marsupilami79@gmx.de>; pgsql-odbc@lists.postgresql.org
Subject: Re: SQLGetConnectAttrW + SQL_ATTR_CURRENT_CATALOG =3D> w= rong byte count?

 

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 <marsup= ilami79@gmx.de>; pgsql-odbc@lists.postgre= sql.org <pgsql-od= bc@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 <marsupilami= 79@gmx.de>
Sent: 22 November 2022 16:57
To: pgsql-odbc@lists.pos= tgresql.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_SA1PR17MB53505D184D6E51B93F7F94A2BE139SA1PR17MB5350namp_--