Release 10.1A: OpenEdge Development:
ADM and SmartObjects

> ## 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:

> - No Application Service is defined for the SmartDataObject.

> - The SmartDataObject is AppServer-aware but its `Configuration` option is set to `Local` in the PRO*Tools Application Partition Deployment utility.

> 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. (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 OpenEdge Development: Open Client Introduction and Programming .

> 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 © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095