Hi, Michelle.

>
>>Automatic locking should not be a big issue if you keep transaction shorts. Automatic retries should do it.
>
>
>The record locking I'm talking about is getting a lock, updating the record, and unlocking it again. Not all my data updating happens in transactions. Just the ones where multiple tables are involved that need to be kept in synch. If I explicitly lock the record instead of letting VFP do it, I know when it failed and can deal with it. Other than that, what I'm doing is really no different than what VFP is doing anyway.

Well, what I'm against of is performing manual locks in general.

>
>Leaving the user the chance to retry "part" of a transaction would imply that they can choose not to, thus producing a rollback after having the transaction on hold too much time. A quick user can decide what to do in -say- two seconds. This is an eternity in DB transaction time.
>
>
>Two seconds is an eternity? Some of these transactions take 3 minutes or more to complete. That's why I wanted to give them the chance to retry rather than making them start the entire transaction over again.

I'm afraid that this is a big problem. I can think of very few processes that can take up so much time. 3 minutes can mean gazillions of records updated. Of course there are circumstances to do that, but in this cases you should take an asynchronous approach, in my opinion, where the user triggers the process, and have some way to check when it ended.

>
>Of course you shouldn't. You have now your BO into the same exe. The day you put it on a COM+ Server, you'll not be there to click any button. 8-)
>>
>>Communication between BO and UI should be done in terms of messages. The best approach from a scalability standpoint is to keep even this communication at a minimum.
>
>
>I have no intention of putting code in the BO. What I was asking was how to send a message up to the UI without losing the place in the BO. Instead of running all the code through to the end and then getting the message in the BO, I'd like to "bookmark" my place, go back to the UI, get an answer, and then optionally return to the BO. Basically the same thing that happens when an actual error occurs. If an error happens, the error handler kicks in, asks the user what to do, and retries the same code if needed. I'm looking for the same sort of thing for problems that are caught by me and not VFP.

>Well, you haven't really answered my question... I'm asking "is this possible?" and you're saying "don't do it" :) It's been interesting reading, though, either way, so worth the post.

Ok. Of course, it is possible. Is it good practice? I think not at all. My opinion and advise is that this need should be addressed by a refactoring the design.

Best luck,