FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

Frediano Ziglio <freddyz77 AT tin.it> wrote:
> Lowden, James K ha scritto:
> > 
> > Two choices: make FreeTDS emulate Microsoft's driver, or make
> > DBD::ODBC do the right thing.  I think #2 is better, if only because
> > being bug-compatible is hard: Sybase's driver will have different
> > bugs.  
> 
> I don't like to fill our driver of workaround for others package bugs.
...
> DBD::ODBC should be fixed... 

Agreed.  

> > 1.  0.63 + odbc_err_handler + (severity < 11) is OK
> > 2.  odbc_err_handler requires odbc_async_exec.  One of these affects
> > DBD::ODBC's ability to recognize RAISERROR messages.  
> > 3.  DBD::ODBC does not cope with higher severities.  
> 
> I would proceed in this way (not in order)
> - (opt) provide a patch for DBD::ODBC 1.13 to fix this issue (on our ML
> too)

That's still a bit of a challenge.  I don't have a Windows development box
at home, and am not usually free at work to putz with FreeTDS.  That said,
I think I can make a reasonable bug report.  The fix will be harder.  

BTW, you may find this discussion interesting:

http://www.nntp.perl.org/group/perl.dbi.dev/1289

OTOH, patching DBD::ODBC so that it specifically works with FreeTDS --
ignoring the behavior of Microsoft's driver -- would be relatively easy,
provided the driver itself works....

> - (opt) updated 20SqlServer.t (see http://svn.perl.org/modules/dbd-
> odbc/trunk/t/20SqlServer.t) to test this issue

Good idea.  

> - post a detailed message to DBI and Jeff to let he know

I've about worn out Google looking for another report like this.  AFAICT
it's an unknown problem.  Two problems, actually:

1.  Getting it to work with the stock ActiveState distribution and
Microsoft's driver.  
2.  Getting it to work with FreeTDS (which will not swallow the error).  

> - update FreeTDS tests to catch all these problems (and fix them), 

Yay!  Looks like I'm committed to helping out in that area.  BTW, you said
in another post:

> To improve test accuracy I would implement a test coverage script using
> GCC... I think that many functions still lack a test.

Is there some automated way of using gcc to implement test coverage?  Or
did you mean to use autoconf somehow?  

> it
> would be fine in 0.64 to read data like MS odbc do (I remember a post on
> ML that state for example that after all rows are retrieved (sqlfetch
> returned success but never no data) it can issue another query (perhaps
> this require some change in token handling...).

I remember that we need look-ahead code sometimes.  Be careful, though,
with buffering.  Buffering the whole resultset can make Microsoft's driver
annoying to use.  If the user expects 100,000 rows, why should he have to
wait until the last one arrives before fetching the first one?  

--jkl