I cant say that I have experience with this. In our "GET.KEY" subroutines, we do a READU, check to see if the key exists and if not, increment the sequential key, write back to the control file and recordlocku the file we are generating the key for (along with checking the len() of the key and other particulars - barcoding, field widths on reports,screens, etc...)
I was thinking if you did something similar, but use a READVL then others might not be locked out of the control file while the transaction is in place ? It was just a thought. If you have a properly structured "GET.KEY" routine and all of your programs check to see if the records exists before writing, then this should work without stepping on existing records. We dont use transaction logging here, so this may make no sense at all. Just throwing out an idea. I dont know if READVL is allowed in a transaction. Maybe not, then bad idea. Anthony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Wednesday, June 15, 2005 11:45 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK From: Anthony Dzikiewicz > So, what if you change the READVU to a READVL ? I don't understand what READL buys me. (Not arguing, just looking to understand.) I thought you need a READU in order to do the write within the transaction. By the way, I've only been working with ISOMODE 1, if that matters. cds ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 6/8/2005 -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 6/8/2005 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
