3Tier vs. 2Tier

[emnu]

Hi,

The last 6 years i've worked with progress in 2-Tier environment (C/S). A couple of months agoo i started informing myself on 3-Tier Appserver environment. So, i have some little questions about updating records in 3-Tier environment. I'll try to explains my issues with an example.

2-TIer Client Server
------------------------

Let's think about a simple program to update customer info in the sports2000 database. So we have a program to browse the customer records and a update frame. Let's say we want to update the address information. 2 users are starting the program at the same time, let's presume user A & B. B update the first customer and changes the address info. After commiting these changes, user A still sees the old address info in his browse (unless if there would be a timer proc. to refresh the browse ). When A opens the same first record, he will see the changes made by B (which is normal, there's direct db-connection, new record values are showen). So far 2-Tier

3-Tier Appserver
---------------------

Now let's port the same example to 3-Tier Stateless Appserver.
So far as i understood, we need at least a temp-table like customer, an appserver procedure to catch the first batch of records in the temp table, an appserver procedure which
executes before update, to see if there are changes made to the updating record, and an appserver procedure to commit the changes made.
So to continue with the example above, user A & B are starting
the browse, the appserver proc. for filling the temp-table executes. When A updates a record in the view-port of the browse, an appserver proc. executes to see if the selected record
in the temp-table isn't changed by an other user, if it is, this procedure catches the new record an displays it in the update frame. Now User A can make changes, when he presses the "update" button, the changed temp-table record is commited by an other appserver procedure to the database. At this moment, if the record is locked by another user, user A gets a message back if he still want's to update the record, if not, the commit is canceled.

Is this the right way to think "3-Tier ?"
Thanx for any comment

Emmanuel Nuyttens.
C&C Computers NV
Oudenaarde

 

[Mike Carroll]

It seems okay to me. You can use a 'customer' temp-table if required, but you can also use a 'transport' table that contains a RAW data field for the transfer of any record from any table.

Personally, I prefer your method, using temp-tables that closely match their equivalent DB tables. Although, I like to extend the temp-table by adding another field:

DEFINE TEMP-TABLE tt-customer LIKE customer
FIELD tt-db-rowid AS ROWID.

This appends a new field to the end of the temp-table and this field is used to hold the ROWID of the DB record to which the temp-table record relates. Then there's never any doubt when it comes to synchronization. You can still use the BUFFER-COPY command to copy data from the DB to the temp-table.

The chances are, if you have a very large database, you will need to implement some kind of mechanism to populate the temp-table with a specific number of records on each call.

What you may find useful is the use of persistent procedures within n-Tier environments. Using these will enable you to create an application that will run in both 2-Tier and n-Tier environments from the same 4GL code. So your customers get the choice.

Rather than place each piece of required AppServer functionality in a separate .p, you can combine related operations by creating internal procedures inside a 'library' procedure (another .p).

The advantage is that the library procedure can be run persistently either on the AppServer OR on the client machine. In both cases, you'll get a procedure handle which the client uses to make the calls. So the client procedure doesn't care where the library procedure is actually running, but just uses the handle to access the internal procedures.