VB6.0 > ADO > OLEDB 1.0> IDS7.23 : Locking strategy
Posted in 1999
Topics: Error Codes & Troubleshooting, Transactions, Locking & Isolation
I have a VB6.0 application which reads rows from one table and populates another. Other UNIX based applications may or may not be locking the records with the VB is attempting to read. I'm not interested in the latest value in the source table so my isolation mode is set to dirty read. The VB app commit's many transactions as it's dealing with hundreds of thousands of rows. The VB app fails intermitently with ISAM error 143 (cannot read row, record is locked). How can this happen with the VB app has isolation set to dirty read? What is the best way of setting the isolation mode through ADO? i.e. Use ADO or bypass with .execute method? Thanks in advance. Andy
Since dirty read transactions in Informix are read-only and OLE DB does not give you a way to say that your transaction is read-only, provider in 2.30 CSDK upgrades lock mode to committed read. From what I understand OLE DB spec allows that but it was making people unhappy so it got fixed. In the next version if you set dirty read, you will get dirty read read-only transaction. Leopold Its a known problem with the provider shipped in 2.30 CSDK. Andy McColl <andy.mccoll@vernons.co.uk> wrote in message news:937239283.787.0.nnrp-07.d4f05361@news.demon.co.uk... > I have a VB6.0 application which reads rows from one table and populates > another. > Other UNIX based applications may or may not be locking the records with the > VB is attempting to read. > I'm not interested in the latest value in the source table so my isolation > mode is set to dirty read. > > The VB app commit's many transactions as it's dealing with hundreds of > thousands of rows. > The VB app fails intermitently with ISAM error 143 (cannot read row, record > is locked). > > How can this happen with the VB app has isolation set to dirty read? > > What is the best way of setting the isolation mode through ADO? i.e. Use ADO > or bypass with .execute method? > > Thanks in advance. > > Andy > > > > >