I've certainly used DBD::ODBC with far more than 1800 updates against Oracle and Access. Do you have AutoCommit => 0? It may be more efficient to commit after each transaction instead. If you post code, there might be other suggestions as well.
-Tats
| [reply]
[d/l] |
All this is assuming as well that you aren't commiting until all are deleted. I would recommend AutoCommit => 0 as well. It seems like it would solve your problem. But if the transaction in question is one you would want to roll back as a whole, then maybe this will give you some insight as to where to begin your search to fix this limit.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Engines\Jet 3.5
contains a REG_DWORD called MaxLocksPerFile. When using M$-ACCESS you can hack that number up to avoid that error. I have mine set at 4294967295 (the max of a REG_DWORD)
This is the kind of thing you might want to look for assuming you're on window$. I'm not saying that this specific key is your problem, but rather to consider that it could simply be some arbitrary value in the registry such as this one that is soft limiting you.
| [reply]
[d/l] |
my $dbh = DBI->connect('DBI:ODBC:inst', { PrintError => 0, AutoCommit => 0 });
This is my connection string where the 1800 limitation is reached.
| [reply] |