FreeTDS Development Group

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

On Thu, 01 Dec 2011 08:25:37 +0300
Steve Teale <steve.teale AT britseyeview.com> wrote:

> Presumably MS is committed to TDS in a way that will not readily allow
> them to do away with that.

If efficiency is the aim, Microsoft has very little choice other than
to stick with TDS.  The protocol is very, very lean and, as we've seen,
quite flexible.  (Exercise for the reader: find a single excess
byte in the protocol.)  

Efficiency is not always Microsoft's aim (as I'm sure they'd
acknowledge if you had all 60,000 of them over for a beer), but when it
comes to things as low-level and user-invisible as TDS, efficiency and
scarcity of programming resources are important.  

OT: I had to print 19 pdf documents today at work on my super-duper
W7 box with 8 GB RAM and a quad-core processor.  Can I select 19
files in the File Manager, right click, and print?  No.  Can drag them
to the printer?  How 1980s!  No.  Can I use the FOR statement in
cmd.exe to invoke print.exe?  Yes!  But do they *print*?  No.  

Probably Acrobat Reader can be invoked with /P or something -- IIRC
that what the GUI shell does -- and maybe that could have been
discovered from the help.  But the Help took 20 seconds to *fail* to
appear, and I didn't hold much hope that the command line would be
documented.  Even I have limits.  

Later I found:
http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/intro_to_sdk/DeveloperFAQ.pdf#page=27
Why Acrobat Reader needs to be told the printer name is more than I can
understand. 

In the end, I had to right-click on each file and *wait*
300 miliseconds or so for the menu to appear, then chase down the print
selection and click on that. [1]  This I did 19 times, or 38, depending
on how you count. Then I received 19 helpful "your document has
printed" balloons on the taskbar, each requiring a cancel by zeroing in
that little red X in the upper-right corner.  

No messages when the thing doesn't fulfill the request, and 19 when it
does.  Would it be wrong to infer that fulfulling the request is the
*unexpected* behavior?  Or should Word open a "File saved" balloon 
every time I save a file?  

Efficiency could not have been the goal.  I don't know what the goal
was, but using the computer for *work* couldn't have been a high
priority.  

End OT.  

> Would it make any sense to do a revitalization of DB-LIB - 'SSAPI' -
> as a C interface to specifically address SS, stripping away the
> generality and consequent complexity of ODBC to make something that
> was easier to use for C and C++ programmers.

Well, as you know, Microsoft isn't the only one with programming
resource constraints.  

I'm not sure what you mean by "revitalize".  DB-Library is alive and
well here at FreeTDS.  A tiny amount of complexity is borne to support
TDS 5.0 (and 4.2) but the code would not be made appreciably
simpler by dropping Sybase.  (I take that as your meaning by
"specifically address SS".)  

DB-Library is already simpler than ODBC because 1) there's no DM and 2)
there's no pretention of supporting other, non-TDS, servers.  The lack
of a DM means the db-lib programmer doesn't deal with DM-specific
behavior.  (Ask Frediano about wide characters and 64-bit pointers.)
The lack of pretention makes db-lib "flatter": there are more
functions, but fewer parameters and fewer return codes.  

If you want an easy-to-use C++ library, I recommend dbstreams
(http://sourceforge.net/projects/dbstreams/).  I guarantee any support
questions will be routed directly to the chief engineer.  

There are things db-lib needs to do and doesn't.  The long data model
isn't very good.  There's no support for some odd types e.g. variant.
It is silent on the very existence of character encoding, much less
UCS-2.  There is no "pivot" operation, even though that's plainly
useful and easily done in a client library.  

ODBC supports row- and column-wise bindings, and can fetch and send N
rows at a time.  For db-lib, bindings are always row-wise and in FreeTDS
N is always 1.  In 20 years I've never felt the need for anything else,
and the lack of call for db-lib cursors tells me many people
feel the same way.  (These bindings are helpful for non-TDS servers.
DB2 uses them to effect something similar to bcp.  That's just
another example of complexity introduced by a generic interface.
And of putting it where it doesn't belong.)  

And db-lib is not the perfect C database interface library.  In that,
though, it has a lot of company.  

I don't know what the perfect library would look like, but I know what
a better one would look like: the C standard library.  fopen, fclose,
fread, fwrite, printf, and scanf.  Communicating with a remote
process is *inherently* more complex than I/O with a device, but
line-by-line processing need not be.  

Too bad we're not starting from there.  

--jkl

[1]  What does an idle machine with four 3.2 GHz processors *do* for
300 ms. to bring up the same menu it raised only two seconds before?  I
bet it idles.  I bet that's a GUI setting.