FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Martin, Jeremy
> Sent: Monday, January 10, 2005 5:14 AM
> 
> We have an older RedHat 9 server set up with FreeTDS 0.61.2 and
> DBD::Sybase, running some perl scripts to connect to one of our MS SQL
> servers. I have been trying to get the same perl scripts to work on a
> newer CentOS 3 server (CentOS is a free clone of RedHat Enterprise 3).
> 
> FreeTDS compiles and installs ok. However as far as I can tell it's
like
> "--enable-msdblib" is being ignored. I can run simple queries fine,
but
> the existing scripts I'm trying to get working use a DATEADD command
> which is giving me errors.
> 
> The query is good, I can run it manually and the old scripts are still
> working fine on the RedHat 9 box. The part of the query using DATEADD
is
> like this: ... AND (I.CREATEDATE > DATEADD("n",-60, GETDATE())
...
> I read that --enable-msdblib changes just a few things in FreeTDS, one
> of them being the 'date' part syntax, I guess Sybase doesn't use "n"
for
> minutes. I also tried using "mi" or also 'n' or just plain n but I got
> the same error doing all of those things.  

You got the basic answer from Bill.  

The --enable-msdblib option affects the C interface to db-lib.  It
doesn't affect query processing on the server; DATEADD() is the same
regardless of configure options.  

BTW, you're using 0.61.2.  There are many, many improvements in more
recent releases, and I strongly encourage you to consider the current
release candidate.
(http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-0.63RC8.tar.g
z).  It represents two years of solid work, and will doubtless save you
other headaches.  

> At first I had a very hard time getting freetds to use the
> /usr/local/freetds/etc/freetds.conf, I set up an entry for this server
> just like on our existing RH9 box but it kept ignoring it and trying
to
> use port 4000 instead of port 1433 to connect. I have tried editing
the
> configure script and hard-coding it to use TDS version 8.0 / port 1433
> by default, but once I set
> FREETDSCONF=/usr/local/freetds/etc/freetds.conf in my environment I
quit
> having to do that.

That's odd, although istr it might have been a problem at one time.  If
you set TDSDUMPCONFIG, you can see where it's looking for freetds.conf.
It should follow the prefix.  

You also mentioned that the same binaries yielded different results on
two different OSes.  Everything I know says that's impossible, barring
extremely unlikely events.  If you have two versions installed, though,
it's entirely possible that you're picking up some version other than
the one you expect.  

One other data point.  Until June 2003, db-lib connected as an ODBC
driver (setting the ODBC bit in the login packet).  As such, connections
acquired ODBC-default settings, including "SET QUOTED_IDENTIFIER ON"
from the server.  After that time, beginning with the 0.62 release,
db-lib more closely emulated the vendors' pre-ANSI implementations.
ODBC and ct-lib continue to get ODBC defaults.  

To check your connection options, you could try something like this:

        create table #t(opt int) 
        declare @i int 
        select @i=1 
        while @i <= 16384 begin 
                insert #t values(@@options & @i) 
                select @i = @i * 2 
        end 
        select * from #t where opt > 0

HTH.  

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.