Skip to Content.
Sympa Menu

freetds - Re: [freetds] Applying Steve Murphee patch (2)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Applying Steve Murphee patch (2)
  • Date: Wed, 30 Jul 2003 05:59:20 -0000


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






Archive powered by MHonArc 2.6.24.

Top of Page