[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Bug in LuaSQL ?
- From: "D Burgess" <david@...>
- Date: Mon, 25 Nov 2002 8:17:23 +1000
I think it is a bug, the statement handle should be closed
and there is no way the gc can do it in this piece of code.
+++++++++++++++++++++++++++++++++
>I'm using luaSQL to manipulate data in Excel tables. I am using a
>modified version with SQLDriverConnect() instead of SQLConnect() like in
>the original code, that enables me to access Excel tables directly
>without the need for DSN database management.
>When writing lots of records to an Excel sheet using a simple "INSERT
>INTO <tab> (...) VALUES (...)" I found the process to stop with an ODBC
>error message "Addtional tables couldn't be opened" [this is the
>translation of the original error string from german DLL version]. This
>happens after approx. 660 records.
>
>Looking into sqlExecute() I found that the handle that is allocated at
>the beginning is not freed when the function returns the number of
>records changed rather than a results table (cursor). Inserting
>SQLFreeHandle (see below with '!!!' comments) fixed my problem. Is this
>a general problem in the package and the de-allocation of the handle is
>also missing at other places? I assume in cases where a cursor object is
>returned, it is the right way to let the handle live.
>
> Last lines in sqlExecute():
>
> /* if there is a results table (e.g., SELECT) */
> if (numcols > 0) {
> return push_cursortable(L, cdata, hstmt, numcols);
> /* action (e.g., UPDATE) */
> } else {
> SQLINTEGER numrows;
> ret = SQLRowCount(hstmt, &numrows);
> if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
> ret = fail(L, hSTMT, hstmt, fatal);
> SQLFreeHandle(hSTMT, hstmt);
> return ret;
> }
> /* !!! THIS LINE INSERTED !!! */
> SQLFreeHandle(hSTMT, hstmt);
> /* END OF INSERTION */
> lua_pushnumber(L, numrows);
> return 1;
> }
>
>Thanks for help.
>
>
>--
>Herbert Leuwer
>herbert.leuwer@t-online.de