Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS + php-sybase_ct on Debian Sarge

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS + php-sybase_ct on Debian Sarge
  • Date: Wed, 14 Sep 2005 10:13:34 -0400

> From: John Fleming
> Sent: Wednesday, September 14, 2005 8:29 AM
>
> On the new cluster, I installed the Debian php4-sybase which uses
> FreeTDS. The first problem I encountered was simply that Sybase
> connections weren't working at all. I quickly realized I had to put
> entries in freetds.conf which at first seemed to solve my problem.
> Except that now about 1/4 hits to the page resulted in a message like
> this:
>
> Warning: sybase_connect(): Sybase: Client message: Login
incorrect.
> (severity 78) in /path/named/hidden/database.phtml on line 25

That message doesn't prevent the query from working. Isn't there any
way to prevent warning messages from replacing data?

> Well, happily, I figured out that setting "tds version" to 5.0 in
> freetds.conf resolved that issue and this particular site and most
> other ones began to work perfectly.

Right: 5.0 + Sybase = Happiness.

> Then, another site was brought to my attention. On loading it,
> the following error would come up instead of the page:
>
> Cannot find the requested character set in Syscharsets: name =
> 'ANSI_X3.4-1968'. No conversions will be done.

FreeTDS is requesting the server send ASCII only, and by the wrong name.
(IIRC, the name should be 'iso_1'.) ASCII is the compilied-in default.
Try setting your client character set to 'ISO-8859-1' in freetds.conf.

If that doesn't work, I'd be interested to see a TDSDUMP log of a
session that spawned that message.

> This confused me at first, but I was able to make things better by
> creating a separate entry in the freetds.conf just for this site
> to use to connect to the Sybase server, and specified "tds version
> = 4.2" just for these connections. Now the site works, again,
> about 1/4 of the time.

I'm confident you'll be much closer to 100% once the character set
issues are resolved. My one concern is that you're using the Debian
FreeTDS package, which is waaay out of date. See Steve Langasek's
message of September 9.

> If I use sqsh from the command line using either login credentials
> (the site that was fixed by setting to 5.0 and the site that was
> broken by setting to 5.0) and tds version 5.0 gives me that
> ANSI_X3.4-1968 character set message. However, that for some reason
> does not cause the site to fail--it works consistently and perfectly.

Right. The server warns you that your requested encoding is
unavailable, but it doesn't drop the link. It's PHP (or your
application, I don't know) that's presenting the server's message
instead of the query's output as data.

> Setting to 4.2 never gives that message, but 25% of the time the
> connection fails.

That's puzzling. TDS 4.2 sessions are a low priority for those of us
actively working on FreeTDS. (Patches always welcome, though!) It's
the least common denominator, or possibly a little less than that. ;-)
The last server that supported only 4.2 was superseded in, oh, 1998 or
so. Whenever Microsoft brought out SQL Server 7.0. Sybase's System 10,
which introduced TDS 5.0, arrived in 1994 IIRC.

Regards,

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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.




Archive powered by MHonArc 2.6.24.

Top of Page