From issues-return-95991-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Mon May 13 13:54:03 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 91460180675 for ; Mon, 13 May 2019 15:54:03 +0200 (CEST) Received: (qmail 964 invoked by uid 500); 13 May 2019 13:54:02 -0000 Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list issues@ignite.apache.org Received: (qmail 792 invoked by uid 99); 13 May 2019 13:54:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 May 2019 13:54:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 90DABE0782 for ; Mon, 13 May 2019 13:54:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 37F4B25813 for ; Mon, 13 May 2019 13:54:00 +0000 (UTC) Date: Mon, 13 May 2019 13:54:00 +0000 (UTC) From: "Igor Sapego (JIRA)" To: issues@ignite.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (IGNITE-11845) ODBC driver works in a wrong way with UTF-16 encoding on Linux MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/IGNITE-11845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-11845: --------------------------------- Description: When ones run a SQL statement, like {{SELECT Id FROM MyTable}}, the value is "garbled" returning a value like {{8\00\05\07\09\0d\09\08\0-\0}} for the the Id column. It's similar to the expected value, though, which is {{80579d98-9010-4610-b12e-ed33ed7d3c62}}. When SQLLine tool is used, the values are not "garbled". This behaviour can be only observed on Linux. It might have something to do with UTF-16 due to a similar [SO question|https://stackoverflow.com/questions/3806305/powershell-2-0-generates-nulls-between-characters] where characters are separated with a \0. Maybe something to do with the UNICODE setting in this line from the ODBC logs h2. Reproducer instructions (in attachment) h3. Build {noformat} docker build . -t ignitegarbleddatareproducer -f IgniteGarbledDataReproducer/Dockerfile {noformat} h3. Execute {noformat} PS C:\IgniteGarbledDataReproducer> docker-compose up Starting ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 ... done Attaching to ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 ignitegarbleddatareproducer_1 | START ignitegarbleddatareproducer_1 | DRIVER={Apache Ignite};ADDRESS=my-ignite-3e8b8cb9a4e192af.elb.us-east-1.amazonaws.com:10800;SSL_MODE=disable; ignitegarbleddatareproducer_1 | Connection Opened ignitegarbleddatareproducer_1 | DROP TABLE IF EXISTS MyTable; ignitegarbleddatareproducer_1 | Table Dropped (if it existed) ignitegarbleddatareproducer_1 | CREATE TABLE MyTable (Id varchar(36) not null, FirstName varchar(255), LastName varchar(255), PRIMARY KEY (Id)); ignitegarbleddatareproducer_1 | Table Created ignitegarbleddatareproducer_1 | INSERT INTO MyTable (Id) VALUES ('80579d98-9010-4610-b12e-ed33ed7d3c62'); ignitegarbleddatareproducer_1 | Data Inserted ignitegarbleddatareproducer_1 | SELECT Id FROM MyTable; ignitegarbleddatareproducer_1 | Id = '8 0 5 7 9 d 9 8 - ' ignitegarbleddatareproducer_1 | Data Returned ignitegarbleddatareproducer_1 | DONE ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 exited with code 0 {noformat} was: When ones run a SQL statement, like {{SELECT Id FROM MyTable}}, the value is "garbled" returning a value like {{8\00\05\07\09\0d\09\08\0-\0}} for the the Id column. It's similar to the expected value, though, which is {{80579d98-9010-4610-b12e-ed33ed7d3c62}}. When SQLLine tool is used, the values are not "garbled". This behaviour can be only observed on Linux. h2. Reproducer instructions (in attachment) h3. Build {noformat} docker build . -t ignitegarbleddatareproducer -f IgniteGarbledDataReproducer/Dockerfile {noformat} h3. Execute {noformat} PS C:\IgniteGarbledDataReproducer> docker-compose up Starting ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 ... done Attaching to ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 ignitegarbleddatareproducer_1 | START ignitegarbleddatareproducer_1 | DRIVER={Apache Ignite};ADDRESS=my-ignite-3e8b8cb9a4e192af.elb.us-east-1.amazonaws.com:10800;SSL_MODE=disable; ignitegarbleddatareproducer_1 | Connection Opened ignitegarbleddatareproducer_1 | DROP TABLE IF EXISTS MyTable; ignitegarbleddatareproducer_1 | Table Dropped (if it existed) ignitegarbleddatareproducer_1 | CREATE TABLE MyTable (Id varchar(36) not null, FirstName varchar(255), LastName varchar(255), PRIMARY KEY (Id)); ignitegarbleddatareproducer_1 | Table Created ignitegarbleddatareproducer_1 | INSERT INTO MyTable (Id) VALUES ('80579d98-9010-4610-b12e-ed33ed7d3c62'); ignitegarbleddatareproducer_1 | Data Inserted ignitegarbleddatareproducer_1 | SELECT Id FROM MyTable; ignitegarbleddatareproducer_1 | Id = '8 0 5 7 9 d 9 8 - ' ignitegarbleddatareproducer_1 | Data Returned ignitegarbleddatareproducer_1 | DONE ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 exited with code 0 {noformat} > ODBC driver works in a wrong way with UTF-16 encoding on Linux > -------------------------------------------------------------- > > Key: IGNITE-11845 > URL: https://issues.apache.org/jira/browse/IGNITE-11845 > Project: Ignite > Issue Type: Bug > Components: odbc > Affects Versions: 2.7 > Reporter: Igor Sapego > Priority: Major > Attachments: Dockerfile, IgniteGarbledDataReproducer.csproj, Program.cs, docker-compose-override.yml, docker-compose.yml, odbc.log > > > When ones run a SQL statement, like {{SELECT Id FROM MyTable}}, the value is "garbled" returning a value like {{8\00\05\07\09\0d\09\08\0-\0}} for the the Id column. It's similar to the expected value, though, which is {{80579d98-9010-4610-b12e-ed33ed7d3c62}}. > When SQLLine tool is used, the values are not "garbled". This behaviour can be only observed on Linux. > It might have something to do with UTF-16 due to a similar [SO question|https://stackoverflow.com/questions/3806305/powershell-2-0-generates-nulls-between-characters] where characters are separated with a \0. > Maybe something to do with the UNICODE setting in this line from the ODBC logs > h2. Reproducer instructions (in attachment) > h3. Build > {noformat} > docker build . -t ignitegarbleddatareproducer -f IgniteGarbledDataReproducer/Dockerfile > {noformat} > h3. Execute > {noformat} > PS C:\IgniteGarbledDataReproducer> docker-compose up > Starting ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 ... done > Attaching to ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 > ignitegarbleddatareproducer_1 | START > ignitegarbleddatareproducer_1 | DRIVER={Apache Ignite};ADDRESS=my-ignite-3e8b8cb9a4e192af.elb.us-east-1.amazonaws.com:10800;SSL_MODE=disable; > ignitegarbleddatareproducer_1 | Connection Opened > ignitegarbleddatareproducer_1 | DROP TABLE IF EXISTS MyTable; > ignitegarbleddatareproducer_1 | Table Dropped (if it existed) > ignitegarbleddatareproducer_1 | CREATE TABLE MyTable (Id varchar(36) not null, FirstName varchar(255), LastName varchar(255), PRIMARY KEY (Id)); > ignitegarbleddatareproducer_1 | Table Created > ignitegarbleddatareproducer_1 | INSERT INTO MyTable (Id) VALUES ('80579d98-9010-4610-b12e-ed33ed7d3c62'); > ignitegarbleddatareproducer_1 | Data Inserted > ignitegarbleddatareproducer_1 | SELECT Id FROM MyTable; > ignitegarbleddatareproducer_1 | Id = '8 0 5 7 9 d 9 8 - ' > ignitegarbleddatareproducer_1 | Data Returned > ignitegarbleddatareproducer_1 | DONE > ignitegarbleddatareproducer_ignitegarbleddatareproducer_1 exited with code 0 > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)