Re: Calling a store procedure

"Jaime Stuardo" <[email protected]>
Newsgroups gmane.comp.db.unixodbc.devel
Organization DESYTEC - Development, Systems & Technologies
Message-ID <003e01ccf224$a998f560$fccae020$@com>
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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

_______________________________________________
unixODBC-dev mailing list
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.