[unixODBC-dev] Calling a store procedure

Jaime Stuardo jstuardo at desytec.com
Thu Feb 23 12:14:08 GMT 2012


Hello and thanks for answering...

SQLExecDirect returns 100. By looking at the header files, that code means
SQL_NO_DATA according to this:

#if (ODBCVER >= 0x0300)
#define SQL_NO_DATA              100
#endif

Since I am using ODBC version 3, I am getting this code which is not an
error actually, but a result condition. The stored procedure does only an
UPDATE and currently it is not updating nothing.

I think that "#define SQL_SUCCEEDED(rc) (((rc)&(~1))==0)" macro should be
updated to include SQL_NO_DATA as a succeeded condition. That is why the
diagnostics does not return any message.

By the way, I used tsql and isql command with the stored procedure and it
worked, so I discarded problem with FreeTDS.

What do you think?

Thanks
Jaime


-----Original Message-----
From: unixodbc-dev-bounces at mailman.unixodbc.org
[mailto:unixodbc-dev-bounces at mailman.unixodbc.org] On Behalf Of Martin J.
Evans
Sent: jueves, 23 de febrero de 2012 6:13
To: Development issues and topics for unixODBC
Subject: Re: [unixODBC-dev] Calling a store procedure

On 23/02/2012 03:05, Jaime Stuardo wrote:
> Hello. I am trying to call a SQL Server 2005 stored procedure by mean of
> a C++ application running under RedHat Linux. unixODBC is installed
> correctly since I can connect to the database.
>
> When I run SQLExecDirect, the returned value is an error. So, here are
> the questions:
>
> .Why does an error occur?
>
> .Why does the SQLGetDiagRec function cannot return the actual error? If
> I generate an error passing a string instead of a date in the second
> parameter, the error is: [FreeTDS][SQL Server]Error converting data type
> varchar to datetime. That means ExtractError function I implemented is
> correct.
>
> This is the code with SQLExecDirect:
>
>      ret = SQLExecDirect(stmt, (SQLCHAR *) query.c_str(), SQL_NTS);
>
>      if (!SQL_SUCCEEDED(ret)) {
>
>          StoreSocket::ExtractError("SQLExecDirect", stmt,
SQL_HANDLE_STMT);
>
>          return false;
>
>      }
>
> Where query is:
>
> execute usp_contrato_actualiza_aclaracion 'uno', '2012-02-22', 'dos',
> 'tres', 'cuatro', '2012-02-14', 'cinco', 'seis', 'siete', 'ocho',
> 'nueve', 'diez', 'once'
>
> And the body of ExtractError is:
>
> **************************
>
> void StoreSocket::ExtractError(
>
>          char *fn,
>
>          SQLHANDLE handle,
>
>          SQLSMALLINT type) {
>
>      SQLINTEGER i = 0;
>
>      SQLINTEGER native;
>
>      SQLCHAR state[ 7 ];
>
>      SQLCHAR text[256];
>
>      SQLSMALLINT len;
>
>      SQLRETURN ret;
>
>      do {
>
>          ret = SQLGetDiagRec(type, handle, ++i, state, &native, text,
>
>                  sizeof (text), &len);
>
>          if (SQL_SUCCEEDED(ret)) {
>
>              printf("%s:%ld:%ld:%s\n", state, i, native, text);
>
>          }
>
>      } while (ret == SQL_SUCCESS);
>
> }
>
> **************************
>
> Any help will be greatly appreciated,
>

In my experience freeTDS sometimes returns an error and then there are 
no diagnostics. I added a special case to Perl's DBD::ODBC because of it 
which raises an error when an ODBC call fails and there are no diagnostics.

Martin

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev at mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev



More information about the unixODBC-dev mailing list