FreeTDS Development Group

[jklowden AT schemamania.org]

On Sat, Jan 22, 2011 at 05:23:13PM -0500, Ken Collins wrote:
> 
> On Jan 22, 2011, at 2:26 PM, James K. Lowden wrote:
> 
> > If memory serves, LPCBYTE is defined in windows.h.  It's not used by 
> > FreeTDS, but is provided in the Microsoft-compatible header file, 
> > sqlfront.h for use by applications.  The versions of winscard.h I found 
> > on the 'net that define LPCBYTE looked very similar to what's in 
> > sqlfront.h, though, so it's hard to see exactly what gcc is complaining 
> > about.  
> > 
> > If I were you, I'd look into why the "TiniTDS" project includes 
> > winscard.h, which supports smartcards.  FreeTDS certainly doesn't need 
> > it. If your aim is cross-compilation, minimizing your include file 
> > dependencies will make your job easier.   
> 
> The TinyTDS project does not include winscard.h (directly, or indirectly 
> that I know of). Our header looks something like this. 
> https://github.com/rails-sqlserver/tiny_tds/blob/master/ext/tiny_tds/tiny_tds_ext.h

That may well be so.  Luis's message of 19 January indicated a compilation 
error on line 39 of sqlfront.h for the preprocessor symbol LPCBYTE which had 
been previously defined on line 22 of winscard.h.  I'm just suggesting that 
including winscard.h in the FreeTDS compilation is unnecessary, and that 
including it is the source of the difficulty.  Many people compile FreeTDS 
using mingw.  

> #ifndef TINYTDS_EXT
> #define TINYTDS_EXT
> #define MSDBLIB
> 
> #include <ruby.h>
> #include <sqlfront.h>
> #include <sybdb.h>
> #include <syberror.h>

Why?  

I realize this isn't documented in the FreeTDS UG, but if you're going to 
write a db-lib wrapper, you need to understand what MSDBLIB does and why 
sqlfront.h and sqldb.h are defined.   

Most important: they're *not* needed for TDS compatibility.  With or without 
them, FreeTDS can connect to and use any Sybase or Microsoft server.   

Sybase and Microsoft define DB-Library differently.  The *API* is a little 
different.  For example, the response to INT_EXIT from an error handler is 
different.  The members of the DBDATEREC structure have different names.  And 
of course SYBCHAR is SQLCHAR and so on, because compatibility never stands 
before competition.  

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.blocks/html/blocks/blocks180.htm

http://msdn.microsoft.com/en-us/library/aa936970%28SQL.80%29.aspx

Sybase originally defined DB-Library and later licensed it to Microsoft, 
which first changed it in subtle ways (as above) and then abandoned it.  
Sybase's header files are 

        sybfront.h
        sybdb.h
        syberror.h

That's all you need to build a perfectly fine FreeTDS application.  If fact I 
doubt syberror.h is needed.  

For Windows compatibility, FreeTDS also includes header files named according 
to Microsoft's conventions:

        sqlfront.h
        sqldb.h

which define all those SQL... manifest constants.  This is helpful to someone 
porting to FreeTDS code originally written to Microsoft's db-lib.  Indeed, 
with a small amount of preprocessor magic, it's possible to use FreeTDS as a 
drop-in replacement for Microsoft's library.  I know a few places where 
that's been done.  

I hope that's clear.  Header files describe a library to the program using 
it.  We have two sets of header files because we emulate two vendors 
descriptions of the DB-Library API.  FreeTDS implements the same protocol 
regardless of the header files -- or even which of the three libraries -- the 
program chooses to use.  

While I'm on the topic, I'll mention that LPCBYTE has been royal pain in the 
tukkus for many years now because it's defined in a variety of Microsoft 
header files.  Because it's defined unconditionally (as a typedef) in their 
version of sqlfront.h, the developer must be careful including other files 
first, a problem made worse by the fact that *some* of windows.h is required. 
 ( WIN32_LEAN_AND_MEAN was always my bad boy.)  

> Luis, I'm rooting for you too :)

Me too!  Let me caution you, though.  None of the FreeTDS utilities use 
sqlfront.h, and all of them connect to Microsoft servers.  The header files 
are written in, um, source code, and everything I've just described can be 
learned from the sources.  By choosing to use sqlfront.h, you bought yourself 
headaches that could easily have been avoided.  Luckily for your users, 
though, you bumped into one early and showed up here!   

Sybase's API definition is cleaner and is still supported by the vendor.  Use 
it unless you have a good reason not to, and you're FreeTDS experience will 
be smoother.  

HTH.  

--jkl