Forum: Ruby DBI question - DBD-ADO query is timing out

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E1f43bafda26307a050d11902752b2a6?d=identicon&s=25 Ball, Donald A Jr (Library) (Guest)
on 2007-06-05 19:29
(Received via mailing list)
Hey guys, I have a tiny DBI question. I'm using DBD-ADO to talk to
sqlserver and have a query that's timing out. Does anyone know how I
might extend the timeout?

- donald
E1f43bafda26307a050d11902752b2a6?d=identicon&s=25 Ball, Donald A Jr (Library) (Guest)
on 2007-06-05 20:48
(Received via mailing list)
> Hey guys, I have a tiny DBI question. I'm using DBD-ADO to
> talk to sqlserver and have a query that's timing out. Does
> anyone know how I might extend the timeout?

Never mind, I found a solution. If working from an ActiveRecord
connection:

connection.instance_variable_get(:@connection).handle.
  instance_variable_get(:@handle).setproperty('CommandTimeout', 3600)

Sure would be nice if something this useful could be manipulated more
elegantly. Perhaps something to add to the todo list for DBI2 if and
when Kirk gets that project off the ground.

Actually, on that note, I just ran into another problem with DBD-ADO,
specifically with the autocommit mode. When it's on, it only commits
after a statement is executed if it thinks it's a read operation. One
problem is, the algorithm fails to treat SELECT INTO statements as write
operations. I would think one would want to commit after all operations
anyway if one's in autocommit mode; it would seem you don't really care
about getting a consistent view of the database in that case.

- donald
This topic is locked and can not be replied to.