Progress
ADM 2 Guide
SmartDataObject Usage Notes
This section provides specific usage notes on several SmartDataObject issues. However, because SmartDataObjects are the heart of any Progress ADM application, all of the remaining chapters of this manual (except "SmartLinks", “SmartLinks”) provide additional information on using them. In particular, see the following sections in "Developing Your Application’s Business Logic":
- "SmartDataObject Query and Update Operations" (RowObject and RowObjUpd temp–tables)
- "Managing SmartDataObjects in Distributed Mode" (Partition property)
- "AppServer Session Operating Modes and SmartDataObjects" (AppServer operating modes and the Force to Stateful Operating Mode property)
- "Running SmartDataObjects in a Distributed Environment" (the client/AppServer configuration for SmartDataObjects)
Setting the Number of Database Rows to Batch
The result set retrieved by a SmartDataObject’s database query is transferred into a Progress temp–table called RowObject that consists of the columns defined for the SmartDataObject. For a description of the RowObject temp–table, see the "SmartDataObject Query and Update Operations" section in Developing Your Application’s Business Logic."
If the query defines a large data set, it might take Progress a considerable amount of time to load all of the database records into this temp–table for transmission to the client. For this reason, Progress transfers rows to the RowObject table a batch at a time, rather than one at a time. The default number of rows to batch, which is stored in the RowsToBatch property, is 200. In many cases, this is a reasonable number. However, you might want to adjust the value of this property up or down depending on your expectations about the database query and how it will be used. You do this by specifying a value for the RowsToBatch fill-in field in the SmartDataObject’s instance property dialog box.
Suppose, for example, that you expect your SmartDataObject’s query to yield a data set that is slightly larger than 200 rows. In this case, you might want to set the RowsToBatch property high enough to retrieve the entire data set when the query first opens. This ensures that there are no further delays if it is necessary to fetch more rows later. Conversely, if the startup time for your application screen is very sensitive, you might be able to improve startup performance noticeably by setting the RowsToBatch property to a very small number, to display the first batch of rows to the user as quickly as possible.
Note that once you set this value at design time, you are not locked into that value for the entire time the application is run. You might choose to set the RowsToBatch property to an initial value at design time, then modify it programmatically at run time, based on the particular query being executed or on other factors.
As a general rule, you should limit the size of the data set that the application code retrieves. Allowing users to browse thousands of records to make a selection is often an inefficient and ineffective way to present data, especially if the records must all be passed across an AppServer connection. Using a SmartFilter or SmartSelect SmartObject or other technique to refine the retrieval to the actual records needed can greatly increase the efficiency of an application and essentially eliminate issues with the size of the data set.
Checking Database Records on Update Attempts
By default, when an application user tries to update a SmartDataObject row, Progress checks whether the database record from which the row was derived has been modified since the record was read into the RowObject temp–table. If so, Progress rejects the update attempt and returns to the client the values that result from the update that occurred since the record was read (by another user) along with an error message, so that the user can make and save the later updates.
NOTE: This check does not include a field-by-field comparison of fields modified by a later user with fields modified by an earlier user. Unless the check is disabled, any change to any field in the record will cause the rejection of a later update.In general, this check for other updates is valuable because it prevents making conflicting changes to a record; specifically, having a later set of changes overwrite an earlier set. In some cases, however, it might not matter whether a record was changed since it was read into the RowObject temp–table. You can set the CheckCurrentChanged property to instruct Progress not to check for earlier updates. Suppose, for example, that your database table contains information such as address data, and it does not matter whether one user changes a field value in this table after another user changes a field value (either the same field or another one in the same table). In this case, the check is not necessary, and you can disable it by unchecking the Check Current Changed toggle box in the SmartDataObject’s instance property dialog box.
Changing How Progress Reloads the RowObject Temp–table
By default, Progress loads the RowObject temp–table from beginning to end. If a SmartDataObject’s query defines a large data set, a fetchLast operation or other reposition to a place far down the data set can result in a significant wait while Progress loads this temp–table. This is because Progress might need to load many batches of rows before it reaches the desired row.
To eliminate this delay, use the SmartDataObject’s RebuildOnRepos property, accessible through the Rebuild Dataset on Reposition toggle box in the instance property dialog box. If you check this toggle box, then whenever a reposition moves to a record that is not already in the RowObject table, Progress performs the reposition in the database query directly and rebuilds the RowObject temp–table from that point.
For example, if the RowsToBatch property is set to 200 for a particular SmartDataObject, the first 200 rows in the database query data set are transferred into the RowObject temp–table when the SmartDataObject’s query is opened. Now, suppose that an application user presses the Last button in an associated SmartPanel or SmartToolbar. Progress repositions the database query directly to the last row, and the RowObject table is rebuilt to contain the last 200 rows in the query. (Note that repositioning to the last row is a very fast operation if the INDEXED–REPOSITION query attribute is set to on and the query can use an index to locate the last record.) Progress extends the RowObject temp–table in both directions as the user scrolls forward or backward.
In general, if a SmartDataObject’s query returns a large data set, you should turn the RebuildOnRepos property to on. However, if the likely number of rows in the data set is not much larger than the setting for RowsToBatch, it is better to leave this property off and get the entire data set.
The Define Temp–Tables Option
Typically, a SmartDataObject directly accesses the database tables for which it is defined. However, the SmartDataObject Wizard provides an option called Define Temp–Tables that you can use at design time to define your own data source. With this option, you define Progress temp–tables for the database tables, which the SmartDataObject accesses instead of the database; each of these temp–tables can contain a subset of the fields in the corresponding database table as well as summary and calculated fields.
NOTE: The temp–tables that this option creates have no connection to the RowObject and RowObjUpd temp–tables that a SmartDataObject uses to manage database data. Those temp–tables are created and maintained automatically.Follow these steps in the AppBuilder to define temp–tables for a SmartDataObject:
- Select the SmartDataObject icon from the AppBuilder palette and specify New. The SmartDataObject Wizard appears.
- Click Next to go to Page 2 of the SmartDataObject Wizard, then click Define Temp–Tables. The Temp–Table Maintenance dialog box appears.
- In the Temp–Table Maintenance dialog box, specify the database tables that you want the SmartDataObject to access, using the Add and Remove buttons as necessary. The AppBuilder will create temp–tables for the tables that you specify.
- Click OK to return to the SmartDataObject Wizard, then click Define Query. The Query Builder appears.
NOTE: The compiler does not support the VALIDATE option on a temp–table field that is defined to be LIKE another temp–table field.- In the Query Builder’s Database field of the Query Builder, select Temp–Tables from the drop-down list, then proceed as usual to build the SmartDataObject’s query.
- Click OK to return to the SmartDataObject Wizard, click Next to go to Page 3, then click Add fields. The Column Editor appears.
- In the Column Editor, specify the fields to be included in the SmartDataObject, then click OK to return to the SmartDataObject Wizard.
- Click Next to finish creating the SmartDataObject.
You must be connected to a database with the name of the temp–table you create to use it. When the SmartDataObject executes the query, it accesses these temp–tables rather than accessing the database tables directly.
NOTE: Progress neither populates the tables that this option creates nor manages any other of their interactions with the database, so you must write the code to perform these activities. If you do not, you will receive a warning message when you run the application, and any visual objects connected to the SmartDataObject will not display data in their fields.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |