New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VARCHAR ARRAY of UTF8 Charset fails [CORE3765] #4109
Comments
Modified by: @jasonwhartondescription: When I connect via UTF8 Charset I get an error: /*--- ERRCODE = 335544321 ERRCODE = 60 ERRCODE = 23 ERRCODE = -1 This is against the Employee.gdb database that comes standard with earlier versions of InterBase. If I change to Charset ASCII then I have no problem getting the data. Somehow something inside the engine is tripping up when it comes to handling UTF8 (MBCS) in array columns. => When I connect via UTF8 Charset and open a query and fetch a record and get the array data I get an error: /*--- ERRCODE = 335544321 ERRCODE = 60 ERRCODE = 23 ERRCODE = -1 This is against the Employee.gdb database that comes standard with earlier versions of InterBase. If I change to Charset ASCII then I have no problem getting the data. Somehow something inside the engine is tripping up when it comes to handling UTF8 (MBCS) in array columns. |
Commented by: @ibprovider Really critical? Very strange :) Hint: forget about official API for work with array and use only isc_put_slice/isc_get_slice. Good luck. |
Commented by: @jasonwharton Ok, I'm going to try and be polite here. YES IT IS CRITICAL! I am using isc_put_slice() and isc_get_slice() and I'm not looking for luck, I'm looking for results. It is currently not possible, as best as I can tell, to make use of array VARCHAR data with UTF8 Charset. This means all of my customers who are trying to migrate apps to Unicode are stuck with no path forward other than to totally rework their apps to not use array columns anymore. This is not acceptable to them as this is a feature/capability that should work. |
Commented by: @asfernandes My personal opinion is (serious) that we should remove arrays from Firebird sooner rather than later. |
Commented by: @AlexPeshkoff Not good idea to remove a feature that people are actively using. |
Commented by: Antonio Fortuny (a.fortuny) Hi all. Alex is right. I'm the guy who asked him some help to deal with arrays and UDFs To be clear, I'm Antonio from Sita Software of Luxemburg. Thanks to Alexander's answers to my questions I get rid of that problem: It works. I'll be now on the way to deal with UTF8, and arrays will appear again for the varchar. And that's probably why Jason comes in because we make an intensive use of IBOs objects as well. Antonio. |
Commented by: @ibprovider > "YES IT IS CRITICAL! " Hm. Very strange. IBProvider reads (now and in 2012 year also) this array-field in connection with UTF8-charset without any problem. I offer to close this ticket :) |
Commented by: @jasonwharton I protest. Note: Yes, I am irritated by how I have been treated so dismissively in this issue. |
Commented by: @ibprovider Why "protest" ? [IBProvider 3.27] SQL: select LANGUAGE_REQ from JOB where JOB_CODE='SRep' and JOB_GRADE=4 and JOB_COUNTRY='France' connection charset: UTF8 (irrelevant, because LANGUAGE_REQ has NONE charset) [Connection through fbclient.dll] Data from isc_get_slice (75 bytes): [Direct connection to Firebird through INET-protocol (TCP/IP)] Data from op_get_slice (75 bytes): NOTE: My currect code obtains the VARCHAR-array as CHAR-array (for avoid the CORE1588). My previous versions, which received the VARCHAR-array as VARCHAR-array (by fact, server returns the CSTRING-array, see CORE1588), also worked without problems. ---- |
Commented by: @jasonwharton Simple answer: I protest because the problem has not been fixed. |
Commented by: @ibprovider Read array's blob directly and you get the VARCHAR-array without any problem. It is not difficult. |
Commented by: @jasonwharton Of course it isn't difficult. I'm not here groveling for tech support. |
Commented by: @ibprovider Look to CORE2500 Use "isc_blr_text2" and "isc_blr_varying2" (with explicit definition of text charset) instead "isc_blr_text" and "isc_blr_varying". Good luck. |
Submitted by: @jasonwharton
When I connect via UTF8 Charset and open a query and fetch a record and get the array data I get an error:
(From the IBO SQL trace monitor)
/*---
GET SLICE
ARRAY ID (129, 501)
ARRAY DTYPE 37
ARRAY SCALE 0
ARRAY LENGTH 15
ARRAY DIMENSIONS 1
ARRAY RELATION 'JOB'
ARRAY FIELD 'LANGUAGE_REQ'
SLICE DATA LENGTH 310
SLICE DATA:
1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
7: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
10: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
11: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
12: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
13: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
14: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
16: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
17: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
18: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ~~~~~~~~~~~~~~~~~
19: 0 0 0 0 ~~~~
ERRCODE = 335544321
----*/
/*---
INTERPRET BUFFER =
ERRCODE = 60
----*/
/*---
INTERPRET BUFFER = arithmetic exception, numeric overflow, or string truncation
ERRCODE = 23
----*/
/*---
INTERPRET BUFFER = string right truncation
ERRCODE = -1
----*/
This is against the Employee.gdb database that comes standard with earlier versions of InterBase. If I change to Charset ASCII then I have no problem getting the data. Somehow something inside the engine is tripping up when it comes to handling UTF8 (MBCS) in array columns.
The text was updated successfully, but these errors were encountered: