On Mon, Jun 8, 2009 at 4:02 PM, MB Software Solutions General Account<[email protected]> wrote: > We've got a vendor here at my day job where they are having a problem > generating unique keys for new records in a table. They claim to be > locking the record, incrementing the counter, updating the underlying keys > table, then unlocking the record. This is a DotNet program, though, > working alongside of our VFP9 app. They say they're using the VFP OLEDB > provider only, and for some reason, the NextID values in the keys lookup > table are getting reset to 0. This is NOT a problem with our app as it's > running in hundreds of centers across the world, but now that their app is > in the mix, there's a problem (yet they're claiming that it's not a > problem with their app!!!!! LOL!). > > My question is this: would they run into problems with their approach > (using only VFP OLEDB) if they did NOT all deploy the multi-threaded > runtime? Perhaps they don't need runtimes if they're only using the VFP > OLEDB from their DotNet app????? -------------------------------------------------------------
I do not think that they can issue a LOCK unless they pass back a transactional SQL Statement. Find out if they are stating their code within a trans. -- Stephen Russell Sr. Production Systems Programmer Web and Windows Development Independent Contractor Memphis TN 901.246-0159 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
