From: Ashok N. <apn...@ya...> - 2025-04-25 14:06:40
|
And other posts on the same (DB2 drivers not supporting UTF-8) - SQLAllocHandle of the driver on SQL_HANDLE_ENV failed when connecting to IBM-DB2 database - MATLAB Answers - MATLAB Central<https://www.mathworks.com/matlabcentral/answers/1786300-sqlallochandle-of-the-driver-on-sql_handle_env-failed-when-connecting-to-ibm-db2-database> and windows - DB2 service does not start - Stack Overflow<https://stackoverflow.com/questions/60296057/db2-service-does-not-start> It would really help folks making up their mind on TIP 716 (including me!) if you could spell out your motivation for adding the manifest entry to Tcl. Perhaps there is an overriding benefit to it but without a TIP or any kind of discussion prior to its introduction in Tcl 9, there is no way for anyone to know. /Ashok ________________________________ From: Ashok Nadkarni via Tcl-Core Sent: Friday, April 25, 2025 7:27 PM To: Jan Nijtmans; tcl...@li... Subject: Re: [TCLCORE] TIP 716 ready for comments Jan, Sorry, could not respond earlier as have been traveling all week. The DB2 error occurs at initialization to the db on a call conn->rc = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv); Conn->rc is the result code (-1 indicating failure), henv would normally contain the returned handle. Any attempt to retrieve additional error information with SQLRegDiagRec fails. I am not sure why but could be because the error retrieval mechanisms also cannot handle a UTF-8 code page. So to elaborate on Harald's correct interpretation of my original post, the failure mode does not involve any Tcl code at all. No data is passed so no encoding mismatch is involved. Your conjecture about Tcl passing it UTF-8 encoded data is off base. It never gets that far to even attempt that (not even as far as SqlConnect). Your comment that Tcl should respect the IBM API is spot on. Except Tcl 9 does not! It is expected that the user's real code page will be retrieved with GetACP() and Tcl 9's manifest hijacks that API to force a UTF-8 return with no recourse or workaround available. How would you suggest the above basic and fundamental API call be written to work around the issue even if the extension writer is willing? To remove Tcl from the equation, also see this issued reported with R 4.2 and DB2 drivers - RODBC odbcConnect fails for ibm db2 connection in Prairie Trillium · Issue #10509 · rstudio/rstudio<https://github.com/rstudio/rstudio/issues/10509>. Guess what R 4.2 and Tcl 9 have in common? The UTF-8 manifest. The motivation for R 4.2 using the manifest is spelled out in the link I included in the TIP. It is completely inapplicable to Tcl for reasons I also outlined in the TIP. I have not looked at the link you included but the failing extension code demonstrating the error is attached. /Ashok ________________________________ From: Jan Nijtmans My guess is that the API used by this IBM DLL is expecting cp1252, but Tcl is providing/retrieving utf-8-encoded data for it. Do you know where the Tcl wrapper-code for this IBM dll is? I think there's nothing wrong with the IBM dll, It's just that Tcl should respect the IBM API. Is the code here? https://github.com/memmertoIBM/db2tcl/ Regards, Jan Nijtmans _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |