Tip classic functions and new pages cohabitation

Switch from new page details to Classic mode in modification

The transition between the version 6 code and the new Versions 7 and above is based on the Classic mode:

• For a Sage X3 version 6 "object", the Classic mode uses the version 6 code and handles the updates on the data managed by the object. The lock is a pessimistic lock, which means that a user using a Classic function on a given record prevents another user from performing a modification on the same record.
• In pure Versions 7 and above mode, for a "persistent class", the updates are done in optimistic lock. At update time, a possible update conflict is detected because the "update tick" has been increased by another user.

The question that comes up is: how are these two functions compatible? In other words, if a user uses a Classic function for an object in which a class exists that supports all CRUD methods, how is the conflict managed between a user modifying a record in Classic mode and another user modifying the same record in Versions 7 and above mode?

The first answer could be that this should not happen: why should a user continue to use the Classic mode if the Version 7 native mode is available? However, the question remains if we consider that the Classic mode handles the complete version 6 object logic while a partial Versions 7 and above native mode can exist for some modification in Mobile mode.

This case has been implemented for the "normal version 6 objects".

To explain how it works, let's consider the following cases:

• A modification starts in Classic mode on record "A". A lock is placed in 'APLLCK', to prevent other Classic sessions to modify this record, but it does not prevent a Versions 7 and above native function to start a modification. If the Classic modification updates the database first, everything is fine and the Updtick is incremented by the update through a database trigger. The version 7 native session will not be able to update the data and a message will be displayed because the Updtick value is no longer the same.
• A modification starts in version 7 native mode on record "A", and just after, record "A" is locked by a Classic session. In Classic, no warning will be displayed because there is no lock on the "A" resource. The Versions 7 and above "object management" used in Classic mode will store the current Updtick value. If the Versions 7 and above native update is done, when the Classic object record will be triggered, a message will also be sent to the user because the Updtick value is no longer the same.

This ensures that both version 6 object mode in Classic mode and Versions 7 and above CRUD updates mode work together.

There is an instance where this is not handled: the "table objects" and the "combined objects". These objects are managed in version 6 mode by a deletion and a recreation of the lines. If this happens, the concurrency control cannot be checked in Classic against Versions 7 and above modifications.

It is therefore recommended not to use Classic mode and Versions 7 and above native mode simultaneously on "table objects" or "combined objects". This should not be a problem because few objects are concerned, and most of these objects are intended for setup operation. Concurrency control issues on this type of objects are not frequent, and thus imposing to use only one of the two modes in such case should not be a big constraint.

Call V7 actions in classic objects

A second step can be done to prepare the transition. This is especially useful if the user interface is complex and not yet fully supported by V7 mode, but if the implementation of CRUD methods can nbe done easily in V7 code.

Implementing creation and/or modification operations in version 7 mode and using them in the scripts associated to objects is possible by using the standard actions in GOBJET ("CREATION", "MODIF"). The developer has then, in the code called from these events:
- to instantiate the corresponding class
- to fill the instances with the data present in the masks
- to call the corresponding method and return errors if some exist

This supposes also to deactivate the database updates done by the supervisor layer. In order to allow deactivating these updates, a local variable called ANOWRITE has been created. This variable must be set to 1 in an event located before the creation (for instance, "INICRE" and "INIMOD") in order to disable standard object CRUD updates.

Typically, the code would look like this:

# SUBMYO associated to MYO object, that uses [MYO1] and [MYO2] masks # The corresponding MYOBJECT class has also creation / update methods$ACTIONCase ACTIONWhen "INICRE" : Gosub INICREWhen "INIMOD" : Gosub INIMODWhen "CREATION" : Gosub CREATIONWhen "MODIF" : Gosub MODIFICATION...When DefaultEndcase...$INICRE : ANOWRITE=1 : Return$INIMOD : ANOWRITE=1 : Return$CREATIONLocal Instance MYOBJ Using C_MYOBJECTLocal Integer OK# Instantiate and assign the values from the maskMYOBJ=NewInstance C_MYOBJECT AllogGroup NullMYOBJ.PROP11=[MYO1]PROP11MYOBJ.PROP12=[MYO1]PROP12MYOBJ.PROP13=[MYO1]PROP13MYOBJ.PROP14=[MYO1]PROP14MYOBJ.PROP15=[MYO1]PROP15MYOBJ.PROP21=[MYO1]PROP21MYOBJ.PROP22=[MYO1]PROP22MYOBJ.PROP23=[MYO1]PROP23# Call the creation method and manage the errorsOK=MYOBJ.AINSERTIf OK=[V]CST_AERRORGOK=0GMESSAGE=...EndifFreeGroup MYOBJReturn$MODIFLocal Instance MYOBJ Using C_MYOBJECTLocal Integer OK# Read the current instance with key found in the mask values (here, only 1 property in the key)MYOBJ=NewInstance C_MYOBJECT AllogGroup NullOK=MYOBJ.AREAD([MYO1]PROP1)If OK=[V]CST_AERRORGOK=0GMESSAGE=...FreeGroup MYOBJReturnEndif# Assign the modified propertiesMYOBJ.PROP12=[MYO1]PROP12MYOBJ.PROP13=[MYO1]PROP13MYOBJ.PROP14=[MYO1]PROP14MYOBJ.PROP15=[MYO1]PROP15MYOBJ.PROP21=[MYO1]PROP21MYOBJ.PROP22=[MYO1]PROP22MYOBJ.PROP23=[MYO1]PROP23# Call the update method and manage the errorsOK=MYOBJ.AUPDATEIf OK=[V]CST_AERRORGOK=0GMESSAGE=...EndifFreeGroup MYOBJReturn