Thread: [ODBC] SQL literal with SJIS hankaku-kana character cause missing escape

[ODBC] SQL literal with SJIS hankaku-kana character cause missing escape

From
TAKATSUKA Haruka
Date:
Hello, psqlODBC team.

We got a bug.
Its reproduce program and log are attached.

An SQL string that contains string leteral ended odd number of
SJIS hankaku-kana character could cause misssing the next escape.

We haven't fixed it yet.

best regards,
Haruka Takatsuka / SRA OSS, Inc. http://www.sraoss.co.jp

Attachment

Re: [ODBC] SQL literal with SJIS hankaku-kana character cause missingescape

From
"Inoue, Hiroshi"
Date:
Hi Takatsuka-san,

How about an attached patch?

regards,
Hiroshi Inoue

On 2017/09/05 14:01, TAKATSUKA Haruka wrote:
> Hello, psqlODBC team.
>
> We got a bug.
> Its reproduce program and log are attached.
>
> An SQL string that contains string leteral ended odd number of
> SJIS hankaku-kana character could cause misssing the next escape.
>
> We haven't fixed it yet.
>
> best regards,
> Haruka Takatsuka / SRA OSS, Inc. http://www.sraoss.co.jp

Attachment

[ODBC] Bug? Data Type Option 'Text as LongVarChar' not working anymore?

From
"Jan-Peter Seifert"
Date:
Hello,

it seems that checking the check box for 'Text as LongVarChar' has no effect anymore.

Starting(?) with v9.6.400?

Best regards,

Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' not workinganymore?

From
"Inoue, Hiroshi"
Date:
Hi,

On 2017/09/13 1:54, Jan-Peter Seifert wrote:
> Hello,
>
> it seems that checking the check box for 'Text as LongVarChar' has no effect anymore.

I can see the effect of 'Text As LongVarChar' here.
Could you tell me unexpected behavior more concretely?

regards,
Hiroshi Inoue

>
> Starting(?) with v9.6.400?
>
> Best regards,
>
> Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' notworking anymore?

From
"Jan-Peter Seifert"
Date:
Hello,

> Gesendet: Mittwoch, 13. September 2017 um 02:05 Uhr
> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>
...
> I can see the effect of 'Text As LongVarChar' here.
> Could you tell me unexpected behavior more concretely?

Test case:
1. Create a DSN choosing 'PostgreSQL Unicode'
2. Call ODBC-function SQLColumns(...) for a column of data type 'text'.

Expected results as for e.g. version 09.03.04.00:
a) Option "Text As LongVarChar" NOT set => data type "SQL_WVARCHAR (-9)"
b) Option "Text As LongVarChar" set => data type "SQL_WLONGVARCHAR (-10)"

Newer psqlODBC versions (e.g. 09.06.04.00 / 09.06.04.10 / 09.06.05.00) always return data type "SQL_WVARCHAR (-9)" -
irrespectiveof the 'Text As LongVarChar' setting.
 

I know that technically text is varchar without a length limit, but our software has to differentiate between these two
datatypes.
 

Best regards,

Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' notworking anymore?

From
"Inoue, Hiroshi"
Date:
Hi,

On 2017/09/13 20:13, Jan-Peter Seifert wrote:
> Hello,
>
>> Gesendet: Mittwoch, 13. September 2017 um 02:05 Uhr
>> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>
> ...
>> I can see the effect of 'Text As LongVarChar' here.
>> Could you tell me unexpected behavior more concretely?
> Test case:
> 1. Create a DSN choosing 'PostgreSQL Unicode'
> 2. Call ODBC-function SQLColumns(...) for a column of data type 'text'.
>
> Expected results as for e.g. version 09.03.04.00:
> a) Option "Text As LongVarChar" NOT set => data type "SQL_WVARCHAR (-9)"
> b) Option "Text As LongVarChar" set => data type "SQL_WLONGVARCHAR (-10)"

How do you set *Unknown Sizes*,  *Max Varchar* and *Max LongVarChar*?

regards,
Hiroshi Inoue

> Newer psqlODBC versions (e.g. 09.06.04.00 / 09.06.04.10 / 09.06.05.00) always return data type "SQL_WVARCHAR (-9)" -
irrespectiveof the 'Text As LongVarChar' setting.
 
>
> I know that technically text is varchar without a length limit, but our software has to differentiate between these
twodata types.
 
>
> Best regards,
>
> Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' notworking anymore?

From
"Jan-Peter Seifert"
Date:
Hello,

> Gesendet: Mittwoch, 13. September 2017 um 13:49 Uhr
> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>

> How do you set *Unknown Sizes*,  *Max Varchar* and *Max LongVarChar*?

Unknown Sizes: Maximum

Max Varchar: 65534

Max LongVarChar: 65534

Best regards,

Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar'not working anymore?

From
"Inoue, Hiroshi"
Date:
Hi,

On 2017/09/13 22:32, Jan-Peter Seifert wrote:
> Hello,
>
>> Gesendet: Mittwoch, 13. September 2017 um 13:49 Uhr
>> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>
>> How do you set *Unknown Sizes*,  *Max Varchar* and *Max LongVarChar*?
> Unknown Sizes: Maximum
>
> Max Varchar: 65534
>
> Max LongVarChar: 65534

Could you set *Max LongVarChar* to 65535?
The current driver returns SQL_(W)VARCHAR for text columns whose length 
<= *Max Varchar*
even though *Text as LongVarChar* is set.

regards,
Hiroshi Inoue


>
> Best regards,
>
> Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' notworking anymore?

From
"Jan-Peter Seifert"
Date:
Hello,

> Gesendet: Mittwoch, 13. September 2017 um 15:47 Uhr
> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>
> Could you set *Max LongVarChar* to 65535?

Thank you very much! This workaround does work. We decreased Max Varchar to 65533 instead though.
It still seems like a bug to me though.

Best regards,

Peter


-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] Bug? Data Type Option 'Text as LongVarChar' notworking anymore?

From
"Inoue, Hiroshi"
Date:
Hi,

On 2017/09/13 23:34, Jan-Peter Seifert wrote:
> Hello,
>
>> Gesendet: Mittwoch, 13. September 2017 um 15:47 Uhr
>> Von: "Inoue, Hiroshi" <h-inoue@dream.email.ne.jp>
>   
>> Could you set *Max LongVarChar* to 65535?
> Thank you very much! This workaround does work. We decreased Max Varchar to 65533 instead though.
> It still seems like a bug to me though.

Hmm, I want to eliminate *Text as LongVarChar*, *Unknowns as 
LongVarChar* or *Unknown Sizes* option if possible.

BTW *UNKNOWNS as LongVarChar* option(default off) would be INVALID for 
PG10 servers.
Are there any problems?
Because 'unknown' type would be 'text' type in PG10, 'unknown' items 
before would be controlled
by *Text as LongVarChar* option(default on).

regards,
Hiroshi Inoue

>
> Best regards,
>
> Peter



-- 
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [ODBC] SQL literal with SJIS hankaku-kana character causemissing escape

From
TAKATSUKA Haruka
Date:
Hello, Inoue-san,

I'm sorry. I missed this mail for long time.

> How about an attached patch?

PsqlODBC 10.00 and later releases including this patch work fine
on our cases.

Thanks,


On Tue, 5 Sep 2017 22:08:26 +0900
"Inoue, Hiroshi" <h-inoue@dream.email.ne.jp> wrote:

> Hi Takatsuka-san,
> 
> How about an attached patch?
> 
> regards,
> Hiroshi Inoue
> 
> On 2017/09/05 14:01, TAKATSUKA Haruka wrote:
> > Hello, psqlODBC team.
> >
> > We got a bug.
> > Its reproduce program and log are attached.
> >
> > An SQL string that contains string leteral ended odd number of
> > SJIS hankaku-kana character could cause misssing the next escape.
> >
> > We haven't fixed it yet.