FreeTDS Development Group

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

> 
> In addition to the new & improved error handling for 
> timeouts, I started
> adding a couple more things:
> 
> 1.  db-lib error messages with placeholders.  In the past, 
> db-lib error
> messases weren't very consistently implemented, meaning that if you
> misused the function it would keep quiet about it until 
> something really
> weird and nasty happened.  Nowadays we try to catch 
> programming errors at
> the API level, so you'll see messages if your error handler 
> is installed. 
> Sometimes those messages would look odd, though, because the 
> placeholder
> substitution wasn't implemented.  It is now, and seems to be 
> working.  
> 
> 2.  TDSVER 0.0.  If you use TDSVER=0.0 for tsql, it will 
> autodetect the
> highest available TDS version and use it.  This doesn't work 
> too well with
> db-lib yet, because the autodetection is really a 
> trial-and-error affair,
> and the db-lib error handler sees it as a fatal logon 
> failure.  I'm not
> *all* that excited about this feature and I'm not sure I'll 
> finish it any
> time soon, but the libtds work is done and demonstrably works.  
> 

Mmm... we could register errors from connection and reply to library
only errors/warning from last connect try. Perhaps server help to detect
version after first connection. It would be useful to cache version
somewhere and be able to detect we are connected to a lower version.

> 3.  The db-lib unit tests no longer produce spurious error 
> messages.  If
> the program is testing that an error is correctly generated, it
> communicates with the error handler and the message is so marked.  
> 

in t0001 there is something strange

 if (argc > 1) {
  printf("server and login timeout overrides (%s and %s) detected\n",
argv[0], argv[1]);
  strcpy(SERVER, argv[0]);
  i = atoi(argv[1]);
  if (i) {
   i = dbsetlogintime(i);
   printf("dbsetlogintime returned %s.\n", (i == SUCCEED)? "SUCCEED" :
"FAIL");
  }
 }

argv[0] should be t0001 not first program argument.

> I look over the db-lib API from time to time.  We're pretty 
> much done.  In
> terms of coverage, I think most of the unimplemented functions are so
> rarely used that no one cares if they're ever done.  I don't see
> registered procedures getting implemented, or the browse functions, or
> "open server", or most of the dbmny functions.  A lot of the remaining
> functions were implemented by only one vendor or the other and never
> really caught on afaict.  
> 

I think our row buffering in dblib is a bit "broken" that is the
behavior is a bit different. For instance it seems from my tests that if
we have 10 row in the buffer when we clear buffer 9 rows goes away, not
all!

> dbsetnull() would be nice, and maybe dbpoll(). Blob handling is a bit
> rough.  The bcp library needs some re-engineering to handle blobs
> correctly, without being limited by virtual memory.  
> 

Yes, dblib bcp needs some works. blobs do not work, streaming in freebcp
would be very fine.

> Looking at how far we've come since 0.60, I think the next 
> release should
> be 0.70.  Which begs the question: what would be 1.0?  Answers:
> 
> 1.  Reworked bcp.  Minimized buffer copies and better charset 
> controls. 
> 2.  A defined set of "will not implement" functions.  

I prefer a "we don't plan to support" :)

> 3.  More compatibility testing with Sybase's implementation.  

I think we should look at DBD::Sybase. I don't have very much time but I
think that the worst thing in ctlib is the way DBD::Sybase read column
type (I don't even remember which function return column
information...).

> 4.  bsqlodbc, so we can script arbitrary ODBC tests.  
> 5.  Correct ct-lib network error numbers and messages, if 
> anyone cares.
> Curently, the "ct-lib" errors generated by libtds are db-lib 
> (-derived)
> values, which ct-lib passes through rather than mapping to 
> the ct/cs-lib
> scheme.  
> 
> That's not a very long list, in programmer years.  Am I 
> missing something,
> or is 1.0 a plausible goal for 2007?  
> 

Mmmm... I would add odbc cursors (not that working) and fix cancel (make
it threadsafe and signal safe).
2007 ?? I don't know... perhaps we should plan a 0.7 :)
Well.. there is wide character support for odbc for instance.
I think that dblib is complete at 90%, odbc 70%, ctlib 60% (with some
problems)

freddy77