FreeTDS Development Group

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

> 
> > Il mer, 2004-09-01 alle 20:05, Michael Kochetkov ha scritto:
> > > Hello,
> > > I have the following problem with FreeTDS 0.62 and 0.63: 
> > the library I use
> > > calls SQLNumResultCols after SQLPrepare (before SQLExecute).
> > > SQLNumResultCols returns SQL_SUCCESS, but the number of 
> > result columns is
> > > set to 0. SQLNumResultCols returns the correct number of 
> > columns in the
> > > Windows platform.
> > > The problem was discussed here a little bit earlier:
> > > 
> > https://lists.ibiblio.org/sympa/arc/freetds/2004q2/016335.html.
>  I have read
> > > it as it shall work for 0.63. But it does not.
> > > Here goes the question: do you plan to support the SQLPrepare ->
> > > SQLNumResultCols -> SQLExecute function sequence? And if 
> you do then
> what
> > > are approximate time constraints?
> [...]
> > 
> > 0.63 should work (see prepare_results tests)... 
> Sorry, I am newbie here. Where I can find FreeTDS regression logs?
> 
> > Which statement are you trying to prepare?
> 
> The statement is "exec sp_columns 'T0007'". T0007 is the test 
> table. The
> correct answer for SQLNumResultCols is 19. I get it as expected on my
> Windows box. The test code, MS SQL Server and the table are 
> the same for
> Unix and Windows client test programs.
> 

Still not supported and not in our road map...
However ms odbc driver behavior it's quite strange..
"exec sp_columns 'sysobjects'"  works
"exec sp_columns ?"             do not works (even with binded columns,
SQLNumResultCols return success but 0 columns)
"{call sp_columns(?)}"          works (driver used ' ' as table name..
why not with previous statement??)

To read column informations ms odbc driver use "SET FMTONLY ON your
statement SET FMTONLY OFF" syntax, even for "{call xxx}" statements.
I suggest you to use SQLExecute before SQLNumResultCols cause it's more
compatible and faster (you avoid an extra road-trip with the server).

freddy77