btw -- this is VFP9SP1. On Mon, June 8, 2009 5:02 pm, MB Software Solutions General Account 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????? > > > Request for ideas please....thanks in advance!!!!!! > --Mike > > > > Mike Babcock, MCP > MB Software Solutions, LLC > President, Chief Software Architect > http://mbsoftwaresolutions.com > http://fabmate.com > http://twitter.com/mbabcock16 > > > > [excessive quoting removed by server]
_______________________________________________ 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.
