Browse Prior Art Database

Solve Data Integrity Problem in Direct Connect

IP.com Disclosure Number: IPCOM000104889D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 98K

Publishing Venue

IBM

Related People

Dawson, CA: AUTHOR [+2]

Abstract

Assume a client-server calendar application that uses legacy applications like OfficeVision/VM* and OfficeVision/MVS* for its service and that has a graphical front-end running in OS/2* or DOS Windows**. Also assume that the design point for this application requires that some part of the server data is shadowed locally on the client for the end user to work with. This local data enhances performance and permits disconnected user support.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Solve Data Integrity Problem in Direct Connect

      Assume a client-server calendar application that uses legacy
applications like OfficeVision/VM* and OfficeVision/MVS* for its
service and that has a graphical front-end running in OS/2* or DOS
Windows**.  Also assume that the design point for this application
requires that some part of the server data is shadowed locally on the
client for the end user to work with.  This local data enhances
performance and permits disconnected user support.

      Current*, with OV/VM workgroup support, is a good working model
of this kind of application and it represents the state-of-the-art
for this kind of 'direct connect' application.

      All the user's host data cannot be shadowed on the PC.  The
performance and storage implications are obvious.  However, the user
can determine how much data to shadow on the PC.  This is called the
synchronization range (sync range).

      The data can be updated from the PC or from the host, and at
regular time intervals, the host data (for the requested sync range)
is downloaded to the PC to compare the two and the updated host
information is modified on the PC.

      A synchronization file (sync file) is maintained with all of
the transactions sent to the host and this sync file is what is used
to compare with the host data that is retrieved.  Each time
synchronization occurs, this host-data file replaces the old sync
file.  However, the host file only contains data for the sync range,
so transactions on events outside the sync range are lost.

      The problem with the current solution occurs when an event is
added on the PC outside the sync range, and then either modified or
deleted on the host.  This new information is not sent down to the PC
and by the time the data rolls around that contains the event, the
sync file no longer contains the original information, so the wrong
comparisons are made and the host and PC get out of sync.

      The design of the synchronization processing was modified so
that changes that are made to future events (outside the sync range)
will be carried forward into the new sync file so that when the
future events fall within the sync range, they will be compared
correctly and there will be no user-perceived loss or corruption of
data.

     Example 1 - deleting the event from the host
     --------------------------------------------

     User adds Event A to the PC and this transaction is sent to
     the host.

          PC                   HOST
        -------               -------
        Event A               Event A

     Event A is deleted from the host

        Event A

     When the day falls inside the sync range, there was no host
     data to send down to the PC and the sync file no longer
     contains a record of Event A, so it is not deleted from the
     PC.

     Ex...