>We are in the process of converting all of our VFP Apps to the Web. I will be using a 3-tier approach (at least I hope). Since this will be my first attempt at total tier separation, I have a few how-best-to-accomplish-this questions.
>
>1. How does one ensure that a user modifying a record via the web have the record locked? I would think locking a record via the web would be difficult because you would never know if the user left their desk, quit without modifying the record, etc. Is record locking even something that is done in a 3 tier type solution?
>

You don't in the normal sense. With an n-tier approach, you need (IMO) to use the techniques best used in client server scenarios.
Option 1: Optimistic locking. The locking is done only at the time of update. If the update doesn't go through, return an error condition, display it to the user and get input as to what to do next (e.g. re-submit).
Option 2: Semaphore locking. Create a "lock" field in your tables. When a user retrieves a record for editing, update the lock field with their ID. If someone else attempts to retrieve the same record, display an appropriate message. The lock is easily cleared by you (or some other process) if the "lock" is left on too long.

>2. We have an application that uses the approach of all or nothing when it comes to transactions. So they may go through 3 or 4 screens of data, affecting several tables during the modification, but if they get to the last screen and fail to enter data or change their mind then all changes should be rolled back to their original state. So can this be handled using a 3-tier solution?
>

Again a couple of options.
Option 1: Create a pageframe for your web UI using dynamic HTML (CSS). That way all changes are submitted on the last page and you don't have to worry about submitting multiple times.
Option 2: Create a temporary staging table(s). Post your changes to these and when the user gets to the last screen, launch a process that posts to the production tables from the staging area.

>Most of my programming expertise has been 2-tier or single tier, where I have the tables I want, I have buffering I need, at the times I need it. So this separation of interface and rules and data is leading me to quite a few questions. Especially since the data tier may be VFP, Access or Oracle in the future.
>

My personal opinion is if you can do 2-tier, you can do n-tier. It's simply a matter of breaking up the pieces into its constituent parts. The communication mechanism is relatively easy. There are so many choices.

The biggest hurdle, I think, for web apps is not the n-tier nature but the stateless nature. You need to pass all the information you will need to perform a task in a single call. That could be an object if your tiers are connected via COM or it could be an XML document if they are connected remotely.

HTH.