FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > > I see no way for the application to know it shouldn't call 
> > > SQLGetData() after SQLNumResultCols() returns nonzero.  
> > 
> > The application should call SQLFetch before SQLGetData.
> 
> Oh! 
> 
> > In odbc 3 you
> > can have even resultset without columns (like inserts or updates!)
> 
> Well, OK, but there's nothing to fetch.  You just mean you can call
> SQLRowCount, right?  
> 
> For this query:
> 
>       INSERT T VALUES (2)
>       UPDATE T SET t = 1
>       DELETE T
> 
> I would expect: 
> 
> 1.  SQLExecute, SQL_SUCEED
> 2.  SQLNumResultCols, 0
> 3.  SQLRowCount, 1
> 4.  SQLMoreResults, TRUE
> 5.  SQLExecute, SQL_SUCEED
> 6.  SQLNumResultCols, 0
> 7.  SQLRowCount, 1
> 8.  SQLMoreResults, TRUE
> 9.  SQLExecute, SQL_SUCEED
> 10. SQLNumResultCols, 0
> 11. SQLRowCount, 1
> 12. SQLMoreResults, FALSE
> 
> Yes? 
> 

No, you don't have to call SQLExecute for every statement. There is also
a problem in TDS protocol which lead to differect behavior if query is
executed with SQLExecDirect and/or cursor are used... To sum up if
client do not use language tokens server do not reply with empty
resultset! Or to be precise if rowcount if on (default) client HAVE to
skip these info to not confuse with RPCs replies... isn't fantastic ??
:)

> Thanks for the SQLFetch advice.  The documentation isn't 
> terribly plain,
> and it wasn't until this morning, after getting your message, 
> that I found
> an example (from IBM) for SQLMoreResults. 
> 

Considering that some odbc 3 drivers still follow odbc 2 rules...

freddy77