Hi, Michelle.

>I've made a point to never put UI code in my business objects and, if an problem occurs, I pass a message back up to the UI. In most cases that's fine. But we've been running into some record locking issues and I was thinking it would be nice to put something in my record locking method that gives them the option to retry or cancel. The problem is that, with my current system, there's no way to retry the code once the problem is passed up to the UI.
>
>I'm wondering how other people handle this? I've looked at the new Try..Catch error handling, and it looks promising, but I'm not sure how I'd go about using it for something like this. Any suggestions?

In my opinion, record locking strategies don't play well with n-tier architectures. This is just one of the issues involved. Generally speaking, a pure n-tier model should be able to work in a fully disconnected fashion. In this case, all you can ask the BO or data tier (whether you have those separated or not) is to know if it was succesful or not, and why. If some problem like this arise, you should just retry the whole operation from the UI.

Can you give me an idea about how your tiers are separated?