Re: Applying Steve Murphee patch (2)

----- Original Message -----
From: "ZIGLIO Frediano" <Frediano.Ziglio@xxxxxxxxxxxx>
To: "FreeTDS Development Group" <freetds@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 29, 2003 5:33 AM
Subject: RE: [freetds] Applying Steve Murphee patch (2)


> ... omissis ...
> >
> > Note on configuration stuff. Steve patch do such change:
> > - remove Servername configuration (using FreeTDS). I'll
> > remove this change cause is not back compatible
> > - add Host (specify address separate from name of server).
> > I'll see MS documentation; there should be a different
> > paremeter for this configuration

Server Name:  The name of the Database Server proper.  This should be our
SERVERNAME.  This would equate to an IBM DB2 database instance name.
Server Host:  The host/machine name.  This should be our HOST on which
SERVERNAME resides.
Server Port:  The port at which SERVERNAME is listening.

This is so that multiple instances of the database can run on the same
machine.  I don't think it is currently supported, but I know that it is
planned.  I have not had a look at M$SQL 2003 yet.  Anyone know if this is
the case for SQL 2003?  But even without multiple instances, SERVERNAME and
HOST can be different.

> Address, syntax like
> Address=xxx.xxx.xxx.xxx,yyy
> (yyy = port)

Then we will have to parse the field to get both parmeters?

> > - some default (like 4.2 protocol, 1433 for port and others).
> > FreeTDS has his own defaults. I'll remove defaults from ODBC
> > - BlockSize. Accepted (perhaps I'll change name if I found a MS one)
>
> Update. Rejected, can be setted with SQLSetConnectAttr.

Hmm...  And remove the ability of the system admins to control write access
to a database at the ODBC configuration level?  It actually should be
handled via authentication and user rights on the database, so scrap it I
guess.  I was just pointing out that it may be useful to someone.

> > - BrokenDates and BrokenMoney. I'll remove. Users should use
> > protocols 7.0 and 8.0 for mssql7 (the problem happen only for
> > early mssql7 versions).

agreed.

> > - Authentication. There is already a MS specific parameter...

My goal was to insulate the system admin or ODBC user from the freetds.conf
file.  The settings were gleaned from what the M$ Windows ODBC driver needed
in combination with what FreeTDS needed.  We should not have to make changes
in both ODBC and the freetds.conf file to add or change ODBC data sources
IMHO.  Any user should be able to configure it from an interface such as the
one provided by unixODBC and the like.  Therefore the ODBC configuration
needs to be able to supply tds with all of it's parameters.  RedHat
distributions (and others as well) come shrink-wrapped with ODBC support in
PHP making the need to compile in ct-lib or db-lib support in PHP frivolous.
My PHP apps are ODBC based.  I connect to IBM DB2, AS/400 DB2, SAP DB, and
now M$ SQL servers with Apache/PHP/ODBC.  No longer do I need to use any
other DBMS connectivity what so ever.  It was a good day when this happened.

Frankly, I did not look for, and find, a TDS implementation for it's ct-lib
and db-lib capabilities.  I was purely interested in ODBC connectivity.
Thus my reason for the attention and time I spent on the FreeTDS/ODBC
support.  Anyone moving from another DBMS, or wishing to include MS SQL
Server in their stable of existing databases might not care to rewrite all
of their apps to the ct-lib/db-lib API or want to get nitty gritty with the
TDS intricacies.  ODBC is perhaps the only thing that I can think of that M$
actually did that I liked.  It at least is a pretence at giving one API to
database independence.  ODBC is not perfect and I doubt it should be used
for all problems at hand.  But I do think it is important to provide good,
easy, and pain free ODBC support.  Even IBM's DB2 Call Level Interface is a
duplicate of ODBC.  Any IBM DB2 app written to the IBM CLI moves instantly
to an ODBC environment with just a library link change.

Also, a person who is used to setting up MSQL ODBC data sources on a Windows
machine should be able to do this quite intuatively on a unix box.  It it is
too different, then their Windows induced thought process will cause them to
"blue screen."  :-)

> > - declaration for unixODBC are in odbcinstex.h (so "BIG hack"
> > shouldn't be required)

This is beacuse odbcinstext.h is not instaled with the distribution of
unixODBC.  Only if you have it in source form do you get
dbcinstext.h.  --with-unixodbc=<unixODBC installed path> will not give you
odbcinstext.h.  Only --with-unixodbc=<unixODBC source path> will do it.  I
don't like it either but I'm not sure how to handle it otherwise.  Negate
the build of the inteface if the source to unixODBC is not present?  I don't
know.  Any other ideas?

Steve