Yes, this is a workaround. But it comes at a cost: Transactions are per connection, not per program. You can't rollback two SQL commands that work on two connections. You can rollback each one separately, but not both at once. And yes, this is an important difference.
If you use more than one connection, use only one distinct conection for database modifications (insert, update, delete), and the other connections only for reading (select). This way, transactions still work.
Another workaround is to buffer the results from the first SQL statement, finish() it, and then process the next SQL statement.
An even better solution is to get a proper RDBMS. There are several available, some even free as in beer and speech.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [d/l] |
| [reply] |
Erm. Sorry to stomp on your sand castle, but ... it's not MSSQL that doesn't allow multiple open resultsets. It's DBD::ODBC. MSSQL does support that, since version 6.0.
"Proper RDBMS". Yeah. Sure. If you want to slander, try to make sure you're not kidding.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
DBD::ODBC does support MAS and MARS, as documented in DBD::ODBC::FAQ. But unlike a proper RDBMS, MAS and MARS require special coding and have surprising side effects. Those problems come from the underlying communication protocol (and probably the MS SQL Server code itself) and do not exist in Oracle, PostgreSQL and other RBDMSs.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |