[erlang-questions] ODBC error after SQL_NO_DATA_FOUND

[Tanmay K. Mohapatra]

Hi Paul,

Thanks for the pointers. I have attached a couple of new patches, one one
R13B03 and the other over commit f3b6a575fceb957805c3b8d8af796a749cbad61c.

I'm new here and don't understand the code fully yet. Though my particular
case is behaving fine now, I'm not sure if I have fixed/tested all
conditions. I had to revert back a change done in get_diagnos where the loop
should break after SQLGetDiagRec returns SQL_NO_DATA.

Reagrds,
Tan

On Thu, Dec 10, 2009 at 5:34 AM, Paul Oliver <puzza007@REDACTED> wrote:

> Hi Tan,
>
> This looks like it could be similar to the bug I observed in
>
> http://github.com/erlang/otp/commit/f3b6a575fceb957805c3b8d8af796a749cbad61c
> .
>  In fact, it looks like you could easily modify that patch to work in
> your case.  Check
> http://msdn.microsoft.com/en-us/library/ms716219%28VS.85%29.aspx for
> details.
>
> Cheers,
> Paul.
>
> On Wed, Dec 9, 2009 at 6:51 PM, tan <tanmaykm@REDACTED> wrote:
> > Hi,
> >
> > I have had a bit of trouble getting erlang to work with iodbc on
> > Darwin (Mac Snow Leopard). I could get odbc to work only after
> > configuring with --enable-darwin-64bit and getting odbcserver to
> > statically link to iodbc. I am using postgresql as my database.
> >
> > The most recent trouble I faced seemed to be because of a call to
> > SQLNumResultCols after getting a SQL_NO_DATA_FOUND during a table
> > update/delete SQL. The odbcserver process exits with error whenever a
> > statement generates SQL_NO_DATA_FOUND. Below is the trace log where
> > the error happens.
> >
> > ================= trace start ======================
> > [000018.849750]
> > odbcserver      7FFF707D2BE0 ENTER SQLExecDirect
> >                SQLHSTMT          0x10020ec60
> >                SQLCHAR         * 0x10020eb91
> >                                  | update game_plays set story_id = 2,
> wher |
> >                                  | e play_id = 101  |
> >                SQLINTEGER        -3 (SQL_NTS)
> >
> > [000018.851035]
> > odbcserver      7FFF707D2BE0 EXIT  SQLExecDirect with return code 100
> > (SQL_NO_DATA_FOUND)
> >                SQLHSTMT          0x10020ec60
> >                SQLCHAR         * 0x10020eb91
> >                SQLINTEGER        -3 (SQL_NTS)
> >
> > [000018.851071]
> > odbcserver      7FFF707D2BE0 ENTER SQLNumResultCols
> >                SQLHSTMT          0x10020ec60
> >                SQLSMALLINT     * 0x7fff5fbfe8ee
> >
> > [000018.851098]
> > odbcserver      7FFF707D2BE0 EXIT  SQLNumResultCols with return code
> > -1 (SQL_ERROR)
> >                SQLHSTMT          0x10020ec60
> >                SQLSMALLINT     * 0x7fff5fbfe8ee
> > ================= trace end ======================
> >
> >
> >
> > To circumvent the issue, I modified odbcserver.c (patch below) to
> > prevent calls to SQLNumResultCols in such cases.
> >
> > Is this fix correct?
> > Did anybody else face similar issues?
> > Is there a better way for getting odbc to work instead of doing a
> > 64bit compile and static linking with iodbc correct?
> >
> > Regards,
> > Tan
> >
> >
> > ================= patch file start ======================
> > 154c154
> > < static db_result_msg encode_result(db_state *state);
> > ---
> >> static db_result_msg encode_result(db_state *state, SQLRETURN
> sql_result);
> > 588c588
> > <       msg = encode_result(state);
> > ---
> >>       msg = encode_result(state, result);
> > 593c593
> > <           msg = encode_result(state);
> > ---
> >>           msg = encode_result(state, result);
> > 815c815
> > <                     msg = encode_result(state);
> > ---
> >>                     msg = encode_result(state, SQL_SUCCESS);
> > 980c980
> > < static db_result_msg encode_result(db_state *state)
> > ---
> >> static db_result_msg encode_result(db_state *state, SQLRETURN
> sql_result)
> > 993c993,998
> > <       DO_EXIT(EXIT_COLS);
> > ---
> >>       if(SQL_NO_DATA_FOUND == sql_result) {
> >>               num_of_columns = 0;
> >>       }
> >>       else {
> >>               DO_EXIT(EXIT_COLS);
> >>       }
> > 1007c1012,1017
> > <       DO_EXIT(EXIT_ROWS);
> > ---
> >>       if(SQL_NO_DATA_FOUND == sql_result) {
> >>               RowCountPtr = 0;
> >>       }
> >>       else {
> >>               DO_EXIT(EXIT_ROWS);
> >>       }
> > ================= patch file end ======================
> >
> >
> > =============== my environment ========================
> > $ erl
> > Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:2:2] [rq:2] [async-
> > threads:0] [kernel-poll:false]
> >
> > Eshell V5.7.4  (abort with ^G)
> >
> >
> > $ uname -ap
> > Darwin tanmac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3
> > 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 i386
> > =======================================
> >
> >
> > ________________________________________________________________
> > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > erlang-questions (at) erlang.org
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20091210/c0442103/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchfile.f3b6a575fceb957805c3b8d8af796a749cbad61c
Type: application/octet-stream
Size: 1098 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20091210/c0442103/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchfile.R13B03
Type: application/octet-stream
Size: 2283 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20091210/c0442103/attachment-0001.obj>