FreeTDS Development Group

["Jorge Cordero" <jorge.cordero AT gmx.net>]

More ideas,

A fast solution may be in the connection string modification. I'm not
familiar with the PHP version, but there should be to way to issue a:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

So you have no longer the blocking problem. BUT: you have to check
what is a transaction and do the proper adjustments to your php code.
For example:
-Remember no COMMITS while there is a pending SELECT...
-What really really need to be in a transaction...
-etc, etc, etc.

A definitive solution: use MySQL... just kidding my friends, just
kidding!!


Regards,

Jorge Cordero






-----Mensaje original-----
De: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org]En nombre de Lowden, James K
Enviado el: Tuesday, September 27, 2005 02:58 PM
Para: FreeTDS Development Group
Asunto: Re: [freetds] MS SQL Server Lockup


> From: RCM2, Inc
> Sent: Tuesday, September 27, 2005 3:36 PM
>
> We are running a Web management package (written in Perl) under
> Apache on Lunux.  We are using FreeTDS to connect to a Microsoft
> SQL 2000 Server.  The connect string is
> dbi:Sybase:server=wbshost;database=testdb
>
> If we stop and start Apache on the Linux box, the SQL server will
> lockup; it will still do selects, but will not do any updates.

[Further to Brian's helpful reply.]

There's not much to go on here.  See if the connection maintained by
your Apache server is being closed on the server.  If there's a SPID,
does it go away when the server is stopped?  Also, is there any
firewall
between the web and database servers?  That could prevent the server
from detecting the client's demise.

It is possible to disconnect rudely from a Microsoft server and leave
the SPID in place.  I have seen this happen with Microsoft's drivers
and
with FreeTDS.

Like Brian, I suspect that the problem with not being able to do
updates
is that the server process begins an update, the Apache process ends
prematurely, but the server process does not.  That would leave the
transaction uncommitted and the locks in place, blocking further
updates.   Your DBA should be able to confirm.

A TDSDUMP of the session might shed some light.

> Any ideals would be appreciated.

Carpe diem.  ;-)

--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.
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds