Skip to Content.
Sympa Menu

freetds - RE: [freetds] problems configuring..

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Russell Kroboth <rkroboth AT visitraleigh.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] problems configuring..
  • Date: Tue, 25 Feb 2003 08:32:49 -0500

I have tried all of the suggestions.. but I still seem to be getting the
same error:

-bash-2.05b# isql -v P450 cgiscript corv3tt31
[unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect

What could it be?



> Try
>
> [P450]
> Driver=TDS
> Description=Partners
> Trace=No
> Server=192.168.1.54
> Database=Partners
> Port=1433
> TDS_Version=7.0
>
> UID is not used, servername refer to a freetds.conf section, server
> refer to direct server. I assumed you have mssql7 or newer (tds 7.0
> version)

Correct, I have SQL Server 2000 I need to connect to. I used the above
information in my template file, then did the following:
odbcinst -u -s -n P450 (To remove the old datasource)
odbcinst -i -s -f tds.datasource.template (Added the new dsn using the new
template)


> > I found /etc/odbc.ini on the system, but it is an empty document. I
never
> > edited this document anyway, I used the instructions on
> > http://www.unixodbc.org/doc/FreeTDS.html to register the driver and
create
>
> Are you sure that's the correct path? I installed from the RPM and the
> name of the installed ODBC driver was different. From my
> /etc/odbcinst.ini:
>
> [TDS]
> Driver = /usr/lib/libtdsodbc.so
> FileUsage = 1
>
> You can use 'odbcinst' to merge that with /etc/odbcinst.ini,
> but I find
> odbcinst really cumbersome and poorly documented. I would
> edit the file
> directly.
>

Correct, I did find the file /etc/odbcinst.ini and it containes:

[PostgreSQL]
Description = ODBC for PostgreSQL
Driver = /usr/lib/libodbcpsql.so
Setup = /usr/lib/libodbcpsqlS.so
FileUsage = 1

[TDS]
Description = v0.60
Driver = /usr/local/lib/libtds.so
FileUsage = 1

I edited it manually just now to make the [TDS] Description = v0.61


> # find / -name "*iodbc*"
>
> ...should not return any files.
>

It did, but I'm not sure these files would affect anything would they?
-bash-2.05b# find / -name "*iodbc*"
/usr/src/redhat/SOURCES/libiodbc-3.0.6.tar.gz
/usr/src/redhat/SPECS/libiodbc.spec


> susb-system installed. This is not good. For example; you should not
> have isql and odbcinst commands in /usr/bin AND
> /usr/local/bin. One of
> them should be removed. In such a case removing the binary

isql and odbcinst exist in /usr/bin but no files at all exist in
/usr/local/bin


> 3. The location of your odbc.ini/odbcinst.ini files can be
> configured a
> number of ways. For example; you have the default, the locations
> configured in the source build, the locations configured in a binary
> install, and what environment variables may say. This is why
> I recommend
> using ODBCConfig or even odbcinst when editing the
> odbc.ini/odbcinst.ini
> files. Assuming a proper install - these tools will use the proper
> locations/files. If you really want to edit the files by hand I would
> recommend that you use the odbcinst command-line tools to
> tell you where
> the location/files are expected.
>
> NOTE: The odbcinst command-line tool was originally created
> to test the
> odbcinst library and was an excuse to create a tool for those
> interested
> in creating install scripts for drivers. ODBCConfig is really
> the way to
> go for most Users.

This is literally a fresh day-old install of Redhat 8. I'm able to use KDE,
although I do prefer to use the command line. I don't have ODBCConfig
installed, so I've been using odbcinst instead. It appears to have been
able to find the file odbcinst.ini file, because I found it and saw the
changes I made to it using odbcinst. However, I found odbc.ini in the same
place (/etc) and it was an empty document. Maybe that is correct at this
point?



> Logging. Set the TDSDUMP and TDSDUMPCONFIG environment
> variables, run your command, and have a look. Very likely FreeTDS isn't
being
> asked to connect to the system you think it is. The top of the TDSDUMP
log shows the
> address, port, and TDS version being used, and if you squint
> you can see the username and password, too.

I set the TDSDUMP and TDSDUMPCONFIG as follows, but nothing appeared as
expected in the files I set:
-bash-2.05b# echo $TDSDUMP
/var/log/freetds/tdsdump.log
-bash-2.05b# echo $TDSDUMPCONFIG
/var/log/freetds/tdsdumpconfig.log





Archive powered by MHonArc 2.6.24.

Top of Page