Re: Noobie, please help!

Gal Rubinstein wrote:
> gcc.exe -c ../common.c -o ../common.o -I"C:/MinGW/include"
> -I"C:/Gal/tmp/freetds-0.82/win32"  -I"C:/Gal/tmp/freetds-0.82/include"
> -D__GNUWIN32__ -W -DWIN32 -DNDEBUG -D_CONSOLE -D_MBCS
> -DFREETDS_SRCDIR=\"..\" -DDBNTWIN32
> 
> In file included from ../common.c:1:
> ../common.h:41:1: warning: "SYBESMSG" redefined
> In file included from C:/Gal/tmp/freetds-0.82/include/sybfront.h:23,
>                  from C:/Gal/tmp/freetds-0.82/include/sqlfront.h:23,
>                  from ../common.h:28,
>                  from ../common.c:1:

That might be my handiwork.  OTOH, I'm not sure you're doing the right
thing be defining DBNTWIN32.  Let's sort a few things out.  

Building FreeTDS for Win32 is a little bit of a novelty.  I don't have
hard figures, but I'd venture to say >95% of FreeTDS users use some flavor
of Unix.  Within the Win32 minority, a fraction use Dev-C++.  None of this
matters -- you can be an army of one -- except that as a trailblazer
you're bound to find the going a little rough, doubly so if you're using
an unfamiliar toolset.  

Also bear in mind that until recently Microsoft provided its own db-lib
(ntwdblib.dll) which works very well within its limitations.  I suspect
FreeTDS's Win32 implementation is picking up steam because Microsoft has,
to say the least, de-emphasized db-lib as a technology, to the extent that
as of 2008 they no longer ship binaries or documentation for it.  Nowadays
you're supposed to master a namespace in a framework on a platform
instead, or something like that.  

Anyway, that's why there's no tutorial.  :-)

That said, we want the db-lib unittests to compile and link against any
db-lib implementation, not just FreeTDS's.  That's something of a gem in
the rough; I'm not sure how well it works.  But that's the intention.  

Microsoft made a lot of gratuitous changes to the db-lib symbols back when
it licensed Sybase's code.  In particular, SYB this became SQL that e.g.
SYBESMSG in Sybase's sybdb.h became SQLESMSG in sqldb.h.  Programs meant
to compile against both vendor's header files need some way to translate
between the two naming schemes.  

FreeTDS follows Sybase's nomenclature for the most part.  I recently added
Microsoft's preprocessor symbols to FreeTDS's sqldb.h, so that if you
include sqldb.h -- as a program written for Microsoft's implementation
would do -- you get Microsoft's symbols.  That helped me get a
formerly-for-Microsoft-dblib Win64 application working (although I
probably wasn't the first).  Those changes are in the nightly snapshot,
not 0.82.  

In src/dblib/unittests/common.h you see the opposite: Sybase's symbols
defined in terms of Microsoft's.  That is done because the unit tests are
written foremost for FreeTDS and use (again) Sybase's nomenclature.  If
you want to compile a unit test against Microsoft's headers (to test
compatability) common.h defines e.g. SYBINT4 for you as SQLINT4, and
Microsoft's sqldb.h defines SQLINT4.  The unit tests use SYBINT4
regardless.  

However, something has to tell common.h to provide Microsoft's names and,
if Microsoft's sqldb.h is to be used, to include windows.h first (because
that's Microsoft's requirement).  What to do?  

We could have made you define, say, USE_MICROSOFT_DBLIB or
DB_LIB_IMPL=MICROSOFT.  But it's simpler, in a way, to check for
DBNTWIN32, which is *not* needed by any FreeTDS code and *is* needed by
Microsoft's header files.  Cf.
http://msdn.microsoft.com/en-us/library/aa936971(SQL.80).aspx.  

Is that documented?  Sort of.  Nowhere in the FreeTDS documentation is
DBNTWIN32 mentioned, because it's not needed.  It is a documented need of
Microsoft's.  So, when DBNTWIN32 is defined, it's reasonable for the code
to infer that the program is being compiled for Microsoft db-lib.  Maybe
not the best solution, but a reasonable one.  

So: the error messages you're seeing relate to the fact that DBNTWIN32 is
defined, but FreeTDS's header files are used instead of Microsoft's. 
They'll disappear if you don't define DBNTWIN32, which afaict you can do
without harm.  

Hope that helps.  

> my boss insists that no ODBC will be used so I presume that db-lib is
> the answer

Yes.  FWIW IMO the boss is right.  (Go, boss!)  Using ODBC adds
complexity.  If you don't need its features, it's easier to use db-lib. 
You might find it adds to your charisma, too, but that's also
undocumented.  

--jkl