You could take a look at your approach... perhaps doing all your work in a
temporary table before making changes in the real one would help. Like Matt
said read the docs, perhaps a simple switch to row-level locking would help.
Also, be sure that your changes are atomic, ie all or nothing, see
Autocommit => 0 for DBI and begin transaction / end transaction / commit /
rollback for Sybase. Then if a resource conflict happened and you had to
kill your DBI script to resolve the issue, you could run it again without
fear that it did half the work already and now it doesn't know how to
recover. transactions really help prevent those probs.
> -----Original Message-----
> From: Vladimir Jebelev [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 12:04 PM
> To: [EMAIL PROTECTED]
> Subject: DBD::Sybase freezes on execute()
>
>
> Hi,
>
> I am having problems with DBD::Sybase when execute() blocks and never
> returns - don't know for sure if it's the driver or maybe the client
> library (I am using DBI 1.14, DBD::Sybase 0.91 and Sybase server 11.0.3 on
> Linux). Once in a while - approximately once per every 10,000 SQL queries
> - could be select, or update, or insert, execute() would block and just
> sit there forever until the process is killed. I worked around this by
> specifying timeout parameter in DSN and retrying execute if failed on
> timeout - unfortunately this isn't perfect since when it fails on insert,
> the data may have been pushed to DB already and the second insert with the
> same data will fail in most cases because of data integrity constraints.
>
> I tried downgrading DBD::Sybase to a few last versions, didn't seem to
> help. Is anyone else experiencing this problem, or will it help if I
> switch to Sybase server 12.0?
>
> Thanks
> Vlad Jebelev
>
>
