Progress
ADM 2 Guide


Service Choices and SmartDataObject Execution

A SmartDataObject that is part of a client-side application runs on the client if either of the following is true:

A SmartDataObject that runs only on the client has its own database connection and accesses the database through that connection.

However, if the SmartDataObject is AppServer-aware and the Application Service on an AppServer host machine is set to an actual service, the client SmartDataObject’s initializeObject procedure establishes a connection to that AppServer, then runs a copy of itself (that is, a file with the same filename) on the AppServer. (Note that if the client is running the client-only SmartDataObject, with the “_cl” suffix, that suffix is ignored when locating the matching SmartDataObject on the AppServer.) The SmartDataObject on the AppServer opens its database query as part of its own initialization. For more information, see the Progress Open Client Developer’s Guide.

When the client-side SmartDataObject runs its openQuery function, the sendRows procedure executes. How this procedure executes depends on whether the application is running in client/server mode or AppServer mode. In client/server mode, when the client uses its own database connection, sendRows retrieves rows from the database and populates the RowObject temp–table, which is then accessed by other objects on the client.

In AppServer mode, however, the sendRows procedure runs clientSendRows. This in turn runs serverSendRows in the AppServer SmartDataObject, which returns the RowObject temp–table to the client. The client-side SmartDataObject uses the temp–table until it is finished with it. It can then either simply exit or execute the closeQuery function, which disconnects it from the AppServer. The same procedures are used to update one or more rows in the table or to add or delete rows as in client/server mode. When the Commit function is run on the client side, it in turn runs serverCommit in the AppServer SmartDataObject, passing a temp–table containing all modified, deleted, or added rows. The serverCommit procedure writes the records back to the database as described in the SmartDataObject description or, if the update fails, returns any errors to the client.

When a 4GL client running a client-side SmartDataObject connects to the same object on an AppServer, the support code for those procedures contains all of the code needed to get updates back to the server. (The support code is located in data.i, which is compiled into each SmartDataObject, and the super procedure data.p.) You can use the same calls from a non-Progress client (for example, a Java client using a proxy built by ProxyGen). However, in this case, if the client process performs any update operations, it is its responsibility to return to the AppServer SmartDataObject an update temp–table that contains those changes. The update temp–table (called RowObjUpd in the 4GL code) must be of the same form as the RowObject temp–table that is passed to the client with the original rows. See the “SmartDataObject Query and Update Operations” section for specifications of this temp–table.

Special considerations apply when you access a SmartDataObject from a Java application. For details, see the "Java Applications and SmartDataObjects" section.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095