If you use distributed DataWindows in the application and plan to migrate the DataWindows to the Web, you must use the workaround provided by Appeon for the distributed DataWindows via:
-
Deriving distributed DataWindows and DataStore objects from appeondatawindow and appeondatastore.
-
Deriving PowerBuilder GetFullState, SetFullState, GetChanges and SetChanges functions from corresponding Appeon functions.
Because the workaround only works with Appeon Server installed to EAServer on Windows, you should avoid using the distributed DataWindow technique if you plan to deploy the application to an Appeon Server running on other application servers.
PowerBuilder GetFullState, SetFullState, GetChanges and SetChanges functions use BLOB (Binary Large Object) parameters for passing DataWindow or DataStore object specifications. Appeon supports BLOB, but it cannot directly interpret the BLOB DataWindow or DataStore object specifications. Appeon workarounds help to interpret the BLOB DataWindow or DataStore object specifications.
Step 1: Apply the workaround appeondatawindow objects and appeondatastore objects provided by Appeon to your application.
For step-by-step instructions on how to apply them, refer to the section called “Appeon GetFullState/SetFullState/GetChanges/SetChanges (Windows only)” in Workarounds & APIs Guide.
Step 2: In PowerBuilder, deploy the server DataStores that are inherited from appeondatastore to Appeon Server.
You also need to deploy the appeondatawindow and appeondatastore objects to the Appeon Server.
Step 3: Generate stubs and skeletons for the server DataStores in the application by following the instructions in the section called “How to deploy NVO to EAServer 6.1” in Workarounds & APIs Guide.
When using the appeondatawindow and appeondatastore objects to work around the distributed DataWindow technique, there are some limitations regarding the use of Appeon GetFullState, SetFullState, GetChanges, and SetChanges functions.
Table 3. Limitations of Appeon workaround
|
Limitation/Difference in |
Limitation/Difference Description |
|---|---|
|
DataWindow styles |
The workaround works with DataWindows or DataStores of all styles, except for OLE and Treeview. |
|
Return value of the functions |
The return value of Appeon SetFullState may have different meaning from that of PowerBuilder system SetFullState function. |
|
The Appeon GetChanges function always returns -1 if it fails. In PowerBuilder, the function can return more error numbers (-1, -2 and -3). |
|
|
The Appeon SetChanges function can return -1 and -3, but cannot return 2 and -2. |
|
|
DataWindow ImportString function |
If using the DataWindow ImportString function in a distributed DataWindow environment, keep the date display format the same at the client and Appeon Server machines. In addition, the date/time format configuration in AEM should be kept the same as the system date/time configuration on Appeon Server. |
|
State information initialization of a DataWindow/DataStore |
In PowerBuilder, the state information of a DataWindow/DataStore is initialized whenever you set its DataObject property. However, if using appeondatawindow and appeondatastore, the state information is initialized only when you change the DataObject property to a different DataWindow object. |
|
Truncation of characters in certain cases |
When applying Appeon SetChanges to a target DataWindow/DataStore, if a column of Char type in the source DataWindow/DataStore has defined more characters than its corresponding column in the target DataWindow/DataStore, characters from the source column that exceed the length limit of the target column are truncated, but in PowerBuilder the extra characters are preserved. |
|
Un-modified or modified data |
When calling PowerBuilder GetFullState and GetChanges, changed (but not accepted) data in a DataWindow control is treated as un-modified data, but if using the Appeon appeondatawindow and appeondatastore, changed (but not accepted) data is treated as modified data. |
