Re: 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.
> 

This is much clear. I though to use syntax line 
Server=myserver/myinstance
For mssql2k+
I never used multiple instance (even on windows..). Can you configure a
DSN for no default instance and see configuration entries ?

> > Address, syntax like
> > Address=xxx.xxx.xxx.xxx,yyy
> > (yyy = port)
> 
> Then we will have to parse the field to get both parmeters?
> 

When I found a MS parameter that can be used I use this parameter, so
you can use windows ODBC knowledge even on unix...
Address is a MS ODBC parameter (for SQL Server ODBC driver). I know we
can use Port to specify port however instead of adding a new Host I
added Address...

> > > - 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.
> 

?? write access ??
I don't catch you ...
However I understand why BlockSize should be useful in odbc.ini too...

> > > - 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...
> 

Mmm... Trusted_Connection if I remember...

> 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 sucvspport 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.
> 

I don't want to remove old server name for two reasons:
- back compatibility (users already configured their odbc.ini file)
- test. It's the faster way to test FreeTDS and ODBC (just use tsql
first and then use Servername, if tsql work ODBC will)

> 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.
> 

MS release ODBC to the community to make it a standard. This standard is
called CLI (Call Level Interface), so CLI is ODBC standard.

> 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?
> 

In my system is installed, however ini.h and log.h are not installed, so
odbcinstex.h does not work. I subscribed yesterday to unixODBC ML to
send a BUG report. IMHO a test in configure and your BIG hack will do...

> Steve
> 

bye
  freddy77