If you were using cached updates with the BDE in order to implement non-standard ModifySQL, DeleteSQL and InsertSQL then you will still be able to implement these same customized DML statements in IBO. InterBase is able to deliver "live" queries for just about every kind of dataset so it may not even be necessary to use them for this reason.
IBO supports the flexibilities of defining custom Update, Insert and Delete SQL statements as well. The delayed cached update behavior is now optional with IBO since you can take control of the DML statements and not have to delay them into a cached updates buffer before being applied.
Using cached updates is like keeping "secrets" from the server. This poses a great challenge to the "server centric" nature of a client/server application. The delaying of an update after it is posted has validation and locking/conflict resolution problems. The server does not have any say over whether there is a validation or integrity violation at the time the user posted the change. Even worse, the user will not be informaed if the change they have just posted will conflict with a change another user has posted.
With the power and flexibility of InterBase transactions unleashed to their fullest extent there is generally no need to delay the updates being posted to the server. Even if it is to try and trick your way around referential integrity in a master-detail relationship there is a way in IBO to manage these situations without CachedUpdates. You can use PostRetaining on the master record so that the user still thinks they are inserting the master record when in fact it has already been sent to the server.
Some use CachedUpdates to fool the server and keep it "ignorant" of what a user is doing until the last second but this model opens the door to data integrity problems. Please use great caution when adopting this model.
If delayed updates being handled in a quick burst is an application requirement then TClientDataset's should also be considered. This is a much better implementation of the briefcase model where updates are made outside of the context of a persistent connection to a server and applied later on. In fact the genius behind this model is that you can disconnect from a server and reconnect later on to complete an operation. IBO's cached updates will hopefully get to this point of capability but not in the immediate future.
