Why not use XLookup functions to gather data from the external DB, perform the calculations locally in the current DB, and then just post the final results back to the external DB?

Carl, I thought about it but it will be posted to only one element. What about the programming execution affects a few other elements in the external database plus some more data manipulations. I believe xpost with capability to execute element change event programming will be a lot more powerful and straight forward.

I certainly won't grant that your mind is in any way "little", and I always wish I had a bigger picture of how Sesame will be used. The users never fail to surprise me much in the same way they surprised Andreas with Q&A 5.0.

There are several problems with XPost running on change code. Chief among these is the danger of "pushing" as opposed to "pulling" data. It causes a inherent data blindness that would be made even more treacherous by code running blind where no one can see what it is doing. It would have to be very carefully crafted code.

Additionally, in Sesame all code (other than Application Open code) is atteched to a particular form, not to a record definition or database. XPost, on the other hand operates directly on records on the server, without specifying one form or another. In that Sesame can have many forms all serving the same database or record definition, the question arises, which form's code applies.

Even if only one form (and at least one) is attached to the database, there are a lot of Sesame commands that are not possible without a user interface. We would need some way to limit the programming only to those commands that can operate directly on fields and records, without forms or elements. And, should we be able to affect that limitation, we would still be very limited in error reporting, and may have to leave a record an "undefined state" with uncommitted changes.

Also, because we are true client / server, as opposed to file sharing / locking, there is a small possibility that between multiple XLookups and XPosts to affect the changes needed, another user could, while using the external application introduce a new record or change an old one so that in the midst of operations the newly altered record becomes the record to be affected by the XPost, instead of the record originally intended. Of course, this would only be true in the case where multiple XPosts and XLookups are combined to affect the change. This is true in any system that does not keep batched result sets and is part of the justification for the XResultSet commands.

Quote:


XPost ("filename", key, "[formName!]ext key element", entry, "target element", "operation")

Mark, we do have to specify the form in the xpost command. So, with xpost command, it has to go through particular form as opposed to working directly on the database record. Just wondering. May be you are eluding to internal working, I guess.