    Note: The following article was submitted to PARADOX INFORMANT for 
          publication in their May 1992 issue.  In order to assist people
          who do not read PARADOX INFORMANT, I am placing this unedited 
          version here on CompuServe in Library 16 (SQL LINK) under the
          Borland PARADOX Databse forum.  Enjoy!  Feedback would be very
          much appreciated.

---------------------------------------------------------------------------
    Copyright 1992
    By William F. Slater, III
    719-495-0726 - Home
    719-260-2018 - Work
    Colorado Springs, CO

    March 25, 1992


                     Two Styles of Client/Server Computing

                               Using SQL LINK

    When I first started writing my most recent set of SQL LINK articles
    (published in PARADOX INFORMANT, Feb. '92 - Apr. '92), it was in the
    fall of 1991.  Since that time I have discovered, along with the rest of
    the computer world, that client/server is a very popular topic.  Indeed,
    while writing a research paper about client/server for the company which
    employs me, I came up with about 85 articles on this subject which were
    published in trade journals and computer magazines since 1990.  The
    remarkable thing about this is that 90% of these articles were dated from
    October 1991 till now.  Clearly, the client/server phenomenon has recently has become a
    major focus in this industry.


    WHAT IS CLIENT/SERVER?

    To begin with, this would be a good point to give a definition of
    client/server:  A software and hardware configuration which divides
    processing efforts between desktop and server platforms.  Database
    operations are performed by a database management system typically a
    larger server platform, while other operations such as data entry,
    queries, graphs, and editing are performed on the smaller desktop
    platform.  In this case, the database server is Rdb/VMS and the clients
    will be PCs which will be running PARADOX with SQL LINK (Rdb/VMS) which
    permits client/server connectivity to Rdb/VMS.


    TWO STYLES OF CLIENT/SERVER COMPUTING

    In keeping with this client/server trend, this article deals with two
    styles of client/server computing which can be accomplished using PARADOX
    SQL LINK.  The two styles are interactive and turn-key systems.  This
    article will be spanning two issues of PARADOX INFORMANT, with the
    interactive style of client/server computing being examined first.  The
    audience for which this article is primarily intended is all who are
    considering using PARADOX with SQL LINK as a front-end to an Rdb/VMS
    database.


    INTERACTIVE CLIENT/SERVER COMPUTING

    By "interactive", I mean using the PARADOX menu commands which become
    extended by having SQL LINK installed with your copy of PARADOX 3.5.  The
    menu commands that you may execute by simply using the menu are basic in
    context, yet powerful enough in execution to get a significant amount of
    client/server work done without having to write a single line of PAL.
    You should be aware that SQL LINK features an SQL editor (similar to the
    PARADOX PAL editor), from which you can execute several different SQL
    menu commands against server database tables.  I plan to cover the uses
    of the SQL editor in another article.


    SERVER DATA = PARADOX DATA?

    One of the biggest advantages of using SQL LINK with a server database is
    that is truly does provide a seamless interface with the server database
    such that the server tables look and handle almost like local tables.
    This fact alone makes SQL LINK a powerful front-end tool with which to
    manipulate the server database tables.


    ACTUAL USES FOR SQL LINK - INTERACTIVE USES

    Let us imagine, for the sake of adding some realism to this article, that
    you come to me with a problem.  Your boss has given you a short notice,
    short time span assignment to perform several client/server activities
    using SQL LINK as a front end and Rdb/VMS as your server database.
    Your biggest problem is that even though you know his requests are
    possible, you have some real uncertainties about specifically how to do
    what he is asking, and the clock is ticking.  So the tasks he has
    requested are listed below along with my suggestions for the best way to
    get these tasks accomplished using SQL LINK.


    CAVEAT "PARADOX-er" (Let the PARADOX User Beware)

    For the new SQL LINK user: Before attempting these activities at your
    company, it would be a very wise idea to have some discussions with your
    Rdb database administrator and your VAX system manager.  The products for
    the client side are easy enough to obtain and install, but they are
    powerful enough in a production systems environment to warrant getting
    sufficient guidance before using them on your own.


    BOSS's REQUEST: GET SQL LINK UP AND RUNNING

    Refer to the PARADOX INFORMANT articles from Feb. - Apr. 1992.  There's a
    three month series of articles covering everything you need to make the
    SQL LINK - Rdb/VMS connection.  That series of articles will help you get
    the SQL LINK product up and running in a very short amount of time.


    BOSS's REQUEST: COPY A LOCAL PARADOX TABLE UP TO THE SERVER DATABASE

    The table is named BIGBUS. The menu commands are:

           {Tools} {Copy} {Table} {Bigbus} {Remote} {COSBUS}


    Note that the target table name on the server had to be different.
    SQL LINK requires this so it will not conflict with the local
    table name.


    BOSS's REQUEST: ADD RECORDS FROM A LOCAL PARADOX TABLE UP TO A SERVER
    DATABASE TABLE

    The local table is named BILLBUS and the server table is named COSBUS.
    It is assumed that the records from the local table are new entries.
    The menu commands are:

           {Tools} {More} {Add} {Billbus} {Cosbus} {NewEntries}



    BOSS's REQUEST: UPDATE RECORDS FROM A LOCAL PARADOX TABLE UP TO A SERVER
    DATABASE TABLE

    The local table is named BILLBUS and the server table is named COSBUS.
    It is assumed that the records from the local table are new entries.
    The menu commands are:

           {Tools} {More} {Add} {Billbus} {Cosbus} {Update}


    BOSS's REQUEST: RETRIEVE ALL LAST NAMES AND PHONE NUMBERS OF COMPANY
    OWNERS WHERE THE COMPANY_NAME IS NOT BLANK IN A SERVER DATABASE TABLE

    The table is named COSBUS. The saved query looks like this:


    Cosbus |    Company_Name     | Last_Name  |   Phone    |
           | CheckPlus NOT BLANK | CheckPlus  | CheckPlus  |
           |                     |            |            |
           |                     |            |            |


    An important concept here is that once you have issued a query to a
    server table, when it completes, the data is then residing in a local
    PARADOX table on your client PC.  This is important for two reasons:
    1)  You must be aware of how much data you are going after or else you
    could exceed the available storage capacity of your PC hard drive;
    (Using this statement in the SQL editor will help you find this
    information: SELECT COUNT (*) FROM table_name); and 2) you must get the
    server data into your PC in PARADOX form in order to be able to use it
    for reports, analysis, graphs, etc.


    BOSS's REQUEST: DELETE ALL RECORDS IN A SERVER DATABASE TABLE
    WHICH HAVE A BLANK COMPANY NAME FIELD

    The table is named COSBUS. The saved DELETE query looks like this:


    Cosbus | Company_Name |
    delete | BLANK        |
           |              |
           |              |


    This type of update is extremely fast.

    Note: Be sure you "commit" this transaction if you plan for your changes
    to be permanent and the AUTOCOMMIT setting is off.  To force a commit at
    any time use this sequence of menu commands:

         [F10] {Tools} {SQL} {Transaction} {Commit}


    BOSS's REQUEST: CHANGE ALL RECORDS IN A SERVER DATABASE TABLE
    WHICH HAVE A BLANK COMPANY NAME FIELD TO "BLANK FIELD"

    The table is named COSBUS. The saved CHANGETO query looks like this:
    (only single line CHANGETO queries are allowed)


    Cosbus | Company_Name                   |
           | BLANK, changeto "BLANK FIELD"  |
           |                                |
           |                                |



    This type of update is also extremely fast, much faster than the {Tools}
    {More} {Add} {Source} {Target} {Update} .

    Note: Be sure you "commit" this transaction if you plan for your changes
    to be permanent and the AUTOCOMMIT setting is off.  To force a commit at
    any time use this sequence of menu commands:

         [F10] {Tools} {SQL} {Transaction} {Commit}


    BOSS's REQUEST: EMPTY A SERVER DATABASE TABLE, BUT LEAVE STRUCTURE INTACT

    Empty the table named TESTDEL with these menu commands

           {Tools} {More} {Empty} {Testdel} {Ok}


    BOSS's REQUEST: ROLLBACK TRANSACTION THAT EMPTIED THE SERVER TABLE -
    WE NEED THOSE RECORDS

    Oops!  You realize you need to get those records back!  Fortunately for
    you, if the AUTOCOMMIT setting was set to "NO", you can ROLLBACK the
    transaction with these menu commands:

           {Tools} {SQL} {Transaction} {Rollback}

    This will cause the server to go to its recovery unit journal to get
    the records which were emptied from the table, and replace them back
    in the server table.


    BOSS's REQUEST: DELETE A SERVER DATABASE TABLE

    Delete the TESTDEL table on the server using these menu commands:

           {Tools} {Delete} {Table} {Testdel} {OK}


    Note: a delete command causes a "commit" which makes these changes
    permanent to the server database.  The delete becomes permanent
    regardless of the AUTOCOMMIT setting.

    Here is a chart to help the SQL LINK user understand the differences
    between EMPTY and DELETE with respect to server database tables:


     Action or Condition               DELETE               EMPTY
    ------------------------     ------------------  -------------------
    AUTOCOMMIT "YES"                Table Deleted       Table Emptied
                                    -PERMANENT-         -PERMANENT-

    AUTOCOMMIT "NO"                 Table Deleted       Table Emptied
                                    -PERMANENT-         -REVERSIBLE-

    Deletes Data?                       Yes                 Yes

    Deletes Table Structure?            Yes                 No

    Can Be Rolled Back Before
    A COMMIT Is Executed?               No                  Yes

    Automatically Commits
    whether AUTOCOMMIT "YES" or "NO"?   Yes                 No

    __________________________________________________________________________

    I hope this clarifies a little more about the use of DELETE and EMPTY
    in operations on REMOTE tables.  I created the chart listed above
    because I am afraid some unfortunate new user is going to get the concept
    of using DELETE and EMPTY mixed up and then after the disastrous
    consequences of using a DELETE (maybe on a REMOTE table that is not yet
    backed up) they may think they can ROLLBACK the transaction.  But once
    you do a REMOTE table DELETE, there is no going back - it is a committed
    transaction whether AUTOCOMMIT is on or not.


    SEEING A TRANSACTION AND A ROLLBACK - WHAT THEY LOOK LIKE

    The following graph is what a server transaction (EMPTY table command)
    looks like while data is being written to the Rdb/VMS Recovery Unit
    Journal file.  This is the information about how the file looked before
    the transaction was started.  This is BEFORE the commit, which would
    prevent a ROLLBACK.  This screen shot was taken using the Rdb/VMS RMU
    Performance Monitor which is packaged with Rdb/VMS.  Note the I/O hits
    on the data file and the RUJ file.

--------------------------------------------------------------------------------
Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   21-MAR-1992 22:24:31
                             Summary IO Statistics
                  For Database: USER3:[SLATER.DEMO]PI_DB.RDB;1
--------------------------------------------------------------------------------


statistic......... max. cur.          10        20        30        40        50
name.............. rate rate +---------+---------+---------+---------+---------+
                             |         |         |         |         |         |
transactions          0    0 |         |         |         |         |         |
verb successes       43   43 +---------+---------+---------+---------+--*      |
verb failures         6    0 |         |         |         |         |         |
                             |         |         |         |         |         |
data file reads      17    4 +---*     |         |         |         |         |
data file writes     13   11 +---------+*        |         |         |         |
RUJ file reads        0    0 |         |         |         |         |         |
RUJ file writes       2    2 +-*       |         |         |         |         |
AIJ file writes       0    0 |         |         |         |         |         |
root file reads       5    0 |         |         |         |         |         |
root file writes      1    0 |         |         |         |         |         |
                             +---------+---------+---------+---------+---------+

--------------------------------------------------------------------------------


    The following graph is what a server transaction looks like during a
    ROLLBACK operation.  Note that data is being read from the RUJ file
    to facilitate the restoring of the table to its original state
    before the transaction was started.  This is BEFORE the commit, which
    would have prevented a ROLLBACK.  This screen shot was taken using the
    Rdb/VMS RMU Performance Monitor which is packaged with Rdb/VMS.  Note the
    I/O hits on the data file and the RUJ file.


Node: BARTLS           Rdb/VMS V4.0A  Performance Monitor   21-MAR-1992 22:37:22
                             Summary IO Statistics
                  For Database: USER3:[SLATER.DEMO]PI_DB.RDB;1
--------------------------------------------------------------------------------


statistic......... max. cur.          10        20        30        40        50
name.............. rate rate +---------+---------+---------+---------+---------+
                             |         |         |         |         |         |
transactions          0    0 |         |         |         |         |         |
verb successes       43    0 |         |         |         |         |         |
verb failures         6    0 |         |         |         |         |         |
                             |         |         |         |         |         |
data file reads      17    3 +--*      |         |         |         |         |
data file writes     20    7 +------*  |         |         |         |         |
RUJ file reads       48   48 +---------+---------+---------+---------+-------* |
RUJ file writes       3    0 |         |         |         |         |         |
AIJ file writes       0    0 |         |         |         |         |         |
root file reads       5    0 |         |         |         |         |         |
root file writes      2    0 |         |         |         |         |         |
                             +---------+---------+---------+---------+---------+

--------------------------------------------------------------------------------


    Anyone who is learning SQL LINK should carefully study Chapter 4
    - A Quick Tour in the SQL LINK User's Guide in order to become
    familiar with the concepts of TRANSACTION PROCESSING.  Before entering a
    "production" development client/server situation, or a "production" user
    situation, one must understand the concepts of CONNECTION to a SERVER
    database, COMMIT of a TRANSACTION, and ROLLBACK of a TRANSACTION.
    Otherwise, such a user or developer is headed for trouble.


    MORE ON THE AUTOCOMMIT FEATURE


    TO SET AUTOCOMMIT TO "YES"

    You must first be attached to an Rdb schema file through SQL
    LINK.  Then the commands to set AUTOCOMMIT from the PARADOX Menu
    are :

              {Tools} {SQL} {Preferences} {Autocommit} {Yes}

    This should be carefully considered when preparing to do this if a
    turn-key application system is being run on the same work station after
    the interactive menu session.  The user may not want to configure SQL
    LINK for AUTOCOMMIT because it could negatively impact the user and the
    programmer of the system if they were depending on a AUTOCOMMIT "NO"
    configuration.

    Set AUTOCOMMIT "On" or Set AUTOCOMMIT "Off" ?

    For some operations when a SQL LINK (Rdb/VMS) user is doing PARADOX
    interactive menu operations against an Rdb table on a VAX, it may be better
    to SET AUTOCOMMIT "YES" BEFORE you start doing operations against an Rdb
    table.  Why?


               1)  If the table has no index, Rdb will lock the table
                   even for read transactions until a COMMIT is executed.
                   This is even true of SELECT statements.

               2)  Operations such as table deletes, creates, and copies
                   not candidates for ROLLBACK anyway.

               3)  Certain transactions such as updates can cause large
                   amounts of write transactions to the server Recovery
                   Unit Journal files.  Performing a commit will reset
                   the RUJ file for a given transaction.

               4)  Open server database cursors, which is the state of a
                   cursor before a commit, can decrease overall server
                   database performance.


    These are some important notes on Transaction Processing from
    "PC WORLD PARADOX 3.5 - Power Programming Techniques"  Page 409
    - 410.

    "Changes are not committed until an explicit commit is executed with

       o   {Tools} {SQL} {Transaction} {Commit}

       o   PAL SQLCOMMIT

       o   A command that PARADOX automatically commits


     Changes are rolled back when {AutoCommit} is set to {No} and

       o   You select {Tools} {SQL} {Transaction} {Rollback}

       o   You select a different connection or a table with a different
           connection

       o   You execute PAL SQLROLLBACK

       o   The server executes an implicit rollback

       o   You select {Tools} {SQL} {Connection} {Break}

       o   You press [Ctrl] [Break] or [Alt] [O]

       o   You execute PAL RUN BIG or DOS BIG


    NOTE:  Certain commands (COPY, CREATE, and DELETE) are always
           committed even if {AutoCommit} is set to {No}. "


    Don't be discouraged or confused about using Rdb and SQL LINK together
    because of this information on AUTOCOMMIT.  Both products work very well
    together.  It's just that a new SQL LINK user needs to remember that they
    are now in the world of server database transaction processing.

    For additional hints about how SQL LINK handles transaction processing with
    Rdb/VMS, read through the PARADOX.RDB note which BORLAND supplies with the
    product.  You will find it in the installation directory.  There are some
    concepts which are very Rdb-specific in these notes.


    CONCLUSION

    This part of this article was written to give the new SQL LINK user a
    flavor for using PARADOX with an Rdb/VMS server.  I hope it gives the new
    SQL LINK user a feel for how much like actual PARADOX the SQL LINK and
    the server tables "behave" in a client/server environment.  But on the
    other hand, I also hope that it enlightens the new SQL LINK user about
    some of the differences that are inherent in the server database
    environment.  The SQL LINK user will have to grasp new concepts to
    understand transaction processing and be able to take full advantage of
    these features.  Caution is advised when experimenting with and learning
    these new transaction processing features, and this product, SQL LINK.
    When the new SQL LINK user can understand these concepts, the integration
    of client and server data will become a productive reality in the
    workplace.

    In the next installment of this article, I will cover some of the PAL/SQL
    language additions that were introduced with the advent of SQL LINK,
    and how professional PAL programmer uses these to build turn-key systems
    which utilize SQL-based database servers.

    If you have questions about this article, or require assistance in using
    PARADOX SQL LINK with Rdb/VMS, please call me at work or at home.  I am
    available until midnight Mountain time and I always enjoy it when people
    call me at work or at home.

    Thank you for your interest.


    Copyright 1992
    By William F. Slater, III
    719-495-0726 - Home
    719-260-2018 - Work
    Colorado Springs, CO
