On Tue, 2003-06-03 at 00:51, [EMAIL PROTECTED] wrote: > Hi! > > I am running a lot of queries through the DBD::Sybase, but lately I've got some > problems with > deadlocks in the Sybase database the DBI connects to. > > The error message: > > DBD::Sybase::st execute failed: Server message number=1205 severity=13 state=1 > line=1 text=Your server command (family id #0, process id #16) was deadlocked with > another process and has been chosen as deadlock victim. Re-run your command. > > I wonder if it has anything to do with the fetch method I am using, I changed this > method to fetch (fetchrow_arrayref) using it together with bind_col. > Earlier I was using the fetchrow_hashrew method, without these kind of problems.
No - this has nothing to do with the fetch method. It is due to two processes that need access to the same resource, usually a select and an update/insert/delete where the order in which the pages (or rows) are locked causes a deadlock. Note that by default Sybase will use a shared lock for selects, and of course uses exclusive locks for update/insert/delete. If two rows are on the same page (and you use page-level locking) then you can get deadlocks fairly easily. Deadlocks problems can be alleviated by altering the table to use row-level locking, and by making changes to the process that performs the DML statement that causes the deadlock. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.mbay.net/~mpeppler Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.mbay.net/~mpeppler/resume.html
