search

lurcher / unixODBC

The unixODBC Project goals are to develop and promote unixODBC to be the definitive standard for ODBC on non MS Windows platforms.
GNU Lesser General Public License v2.1
94 stars 51 forks source link

odbc_util.c:214: odbc_wide2utf: Assertion `p+1-out <= o_len' failed #160

Closed kothapraveen closed 4 months ago

kothapraveen commented 4 months ago

Hi Currently am working with below environment

unixODBC- 2.3.11 gcc540 RHEL7 64 FreeTDS 1.3

my source code(interacting DB with sql statements) is working fine for windows but in linux am facing below assertion

odbc_util.c:214: odbc_wide2utf: Assertion `p+1-out <= o_len' failed

can someone help me to resolve the issue

lurcher commented 4 months ago

I would guess that is coming from FreeTDS. Maybe get some ODBC logs to show whats going on when the error happens. My guess is a buffer size issue with unicode getting involved.

kothapraveen commented 4 months ago

Hi Nick, Thanks for your response. how can we identify FreeTDS issue and resolve .How to get ODBC logs.

after the error<odbc_util.c:214: odbc_wide2utf: Assertion `p+1-out <= o_len' failed> could observe cordump also

lurcher commented 4 months ago

On 08/03/2024 17:02, kothapraveen wrote:

Hi Nick, Thanks for your response. how can we identify FreeTDS issue and resolve .How to get ODBC logs.

after the error<odbc_util.c:214: odbc_wide2utf: Assertion `p+1-out <= o_len' failed> could observe cordump also

— Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/160#issuecomment-1986070258, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62NSAA3A2RTPYGBPONTYXHVLVAVCNFSM6AAAAABEM57N7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGA3TAMRVHA. You are receiving this because you commented.Message ID: @.***>

In odbcinst.ini add

[ODBC] Trace=Yes Tracefile=/tmp/sql.log

And for freetds info

https://www.freetds.org/support.html

kothapraveen commented 4 months ago

Hi Nick,

below are the sql logs

[ODBC][95933][1710138710.574029][SQLAllocHandle.c][578] Entry: Handle Type = 3 Input Handle = 0x2845790 [ODBC][95933][1710138710.574074][SQLAllocHandle.c][1123] Exit:[SQL_SUCCESS] Output Handle = 0x2b053d0 [ODBC][95933][1710138710.574236][SQLPrepareW.c][165] Entry: Statement = 0x2b053d0 SQL = [insert character_datatypes_intl(nvarcharmax, description) values (N'<90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90>...][length = 11138]

but i could not see Exit:[SQL_SUCCESS] message after the above statement.

currently we are using wchar_t nchar_char; nchar_char = 0xc290;

and assigned to the binLongVarCharMaxStr by looping the some charcount ex:36009 OAStringw binLongVarCharMaxStr;

is unicode 0xc290 supported?

could you help us to try other supported unicode characters?

lurcher commented 4 months ago

On 11/03/2024 06:48, kothapraveen wrote:

Hi Nick,

below are the sql logs

[ODBC][95933][1710138710.574029][SQLAllocHandle.c][578] Entry: Handle Type = 3 Input Handle = 0x2845790 [ODBC][95933][1710138710.574074][SQLAllocHandle.c][1123] Exit:[SQL_SUCCESS] Output Handle = 0x2b053d0 [ODBC][95933][1710138710.574236][SQLPrepareW.c][165] Entry: Statement = 0x2b053d0 SQL = [insert character_datatypes_intl(nvarcharmax, description) values (N'<90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90>...][length = 11138]

but i could not see Exit:[SQL_SUCCESS] message after the above statement.

currently we are using wchar_t nchar_char; nchar_char = 0xc290;

and assigned to the binLongVarCharMaxStr by looping the some charcount ex:36009 OAStringw binLongVarCharMaxStr;

is unicode 0xc290 supported?

could you help us to try other supported unicode characters?

Again, I think it would be a better question for the FreeTDS folk, but if you are using the standard wchar_t then unless you are using a compiler flag and lots of heavy lifting, then that's a 4 byte type. unixODBC and AFAIK FreeTDS uses a 2 byte SQLWCHAR. You can get unixODBC to use 4 bytes, but it will need building specially and you still will face the problem of what the driver expects.

kothapraveen commented 4 months ago

Hi Nick,

Thanks for your responses.

currently we are trying to get the username "info type" SQL_USER_NAME from SQLGetInfoW(), but we are getting empty string,but other info types SQL_CATALOG_TERM,SQL_SCHEMA_TERM,SQL_PROCEDURE_TERM we are getting expected values of data sources

lurcher commented 4 months ago

On 12/03/2024 15:57, kothapraveen wrote:

Hi Nick,

Thanks for your responses.

currently we are trying to get the username "info type" SQL_USER_NAME from SQLGetInfoW(), but we are getting empty string,but other info types SQL_CATALOG_TERM,SQL_SCHEMA_TERM,SQL_PROCEDURE_TERM we are getting expected values of data sources

— Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/160#issuecomment-1991997795, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62OFFQW3CFLQRDIS5JTYX4QXBAVCNFSM6AAAAABEM57N7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRHE4TONZZGU. You are receiving this because you commented.Message ID: @.***>

This may sound less helpful than you hoped for, but I just spent 20 minutes doing what you could do instead of posting to unixODBC. I checked the code for FreeTDS 1.4.10 and found this code:

src/odbc/odbc.c

        / TODO finish /     case SQL_USER_NAME:         / TODO this is not correct username /         / p = tds_dstr_cstr(&dbc->tds_login->user_name); /         / make OpenOffice happy :) /         p = "";         break;

So, again, its a FreeTDS question for the FreeTDS folk, or being open source, you could check the code. I can put my Easysoft hat on and say you could use our driver that does return the user name. Or for that matter the Microsoft one if its supported on your platform.

kothapraveen commented 4 months ago

On 12/03/2024 15:57, kothapraveen wrote: Hi Nick, Thanks for your responses. currently we are trying to get the username "info type" SQL_USER_NAME from SQLGetInfoW(), but we are getting empty string,but other info types SQL_CATALOG_TERM,SQL_SCHEMA_TERM,SQL_PROCEDURE_TERM we are getting expected values of data sources — Reply to this email directly, view it on GitHub <#160 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62OFFQW3CFLQRDIS5JTYX4QXBAVCNFSM6AAAAABEM57N7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRHE4TONZZGU. You are receiving this because you commented.Message ID: @.**> This may sound less helpful than you hoped for, but I just spent 20 minutes doing what you could do instead of posting to unixODBC. I checked the code for FreeTDS 1.4.10 and found this code: src/odbc/odbc.c         / TODO finish /     case SQL_USER_NAME:         / TODO this is not correct username /         / p = tds_dstr_cstr(&dbc->tds_login->user_name); /         / make OpenOffice happy :) */         p = "";         break; So, again, its a FreeTDS question for the FreeTDS folk, or being open source, you could check the code. I can put my Easysoft hat on and say you could use our driver that does return the user name. Or for that matter the Microsoft one if its supported on your platform.

Thanks for your comments.It helped us to solve the issue.