Panic when binding `varchar`/`string` types: slice bounds out of range [:668] with capacity 256 about odbc HOT 3 CLOSED

I actually fixed it with a small hack: duneanalytics@ae0055c

But I am unsure whether this is a good idea and whether this is something we can make generic.

from odbc.

Hello @hawkaa

When binding columns, a call to [C.SQLDescribeColW](

odbc/api/zapi_unix.go

Line 44 in 39f8520

r := C.SQLDescribeColW(C.SQLHSTMT(statementHandle), C.SQLUSMALLINT(columnNumber), (*C.SQLWCHAR)(unsafe.Pointer(columnName)), C.SQLSMALLINT(bufferLength), (*C.SQLSMALLINT)(nameLengthPtr), (*C.SQLSMALLINT)(dataTypePtr), (*C.SQLULEN)(columnSizePtr), (*C.SQLSMALLINT)(decimalDigitsPtr), (*C.SQLSMALLINT)(nullablePtr))

is made. This inputs a statement handle, and a column number, and outputs data about the column, including its length. The length returned for the data column is 256. This length is then passed on to NewVariableWidthColumn which rightfully creates a buffer for that column of size 256.
When calling rows.Next(), it reads the first results and tries to fit my 668 length character string into the buffer which is only 256 long which makes the program panic.

Your explanation sounds reasonable. Your ODBC driver uses variable size buffers for SQL_VARCHAR columns, so SQLBindCol ODBC API cannot be used for such columns. SQLBindCol API is memory efficient, because it does not require to allocate buffers every time you read column result.

Your change duneanalytics@ae0055c looks reasonable in your situation. Your approach is sound, it just requires more ODBC calls and more memory allocation / deallocation.

I don't want to accept your change into main repo, because, I believe, that your driver SQLDescribeCol API implementation is incorrect - it returns 256 as column size, and then returns more than 256 of bytes.

Alex

from odbc.

Thank you for a detailed answer, @alexbrainman !

I don't want to accept your change into main repo, because, I believe, that your driver SQLDescribeCol API implementation is incorrect - it returns 256 as column size, and then returns more than 256 of bytes.

Of course that change does not belong in this repository. I just wanted to show you how I worked around the problem. I mean, technically, we could have expanded the API of this library with some bindVarcharColumns setting or similar, but as you say, there's a bug in the underlying driver. I will make sure to report that.

Thank you again!

from odbc.