The key to a good conversion to IBO is to prepare ahead of time before changing component class types to IBO. It is important to know what differences exist between IBO and the BDE. Then, adjustments can be made in the working application under the BDE first.
Knowing what IBO doesn't directly support ahead of time will help determine the amount of work that lies ahead in converting an application to IBO. Take inventory of your applications usage of the BDE based components and compare it to the unsupported features mentioned and then make an estimation of the number of changes that need to be made. Try making those adjustments to get a feel for how quickly this can be accomplished. Be sure to test the application and make sure it is still functioning as expected (whether fully working or not) prior to making the component conversions.
Here is a list of typical changes that applications may need per each component type:
TSession
In most circumstances IBO handles sessions for multi-threading automatically using thread-local storage mechanisms. So, the TSession component may not be necessary and can eventually be removed.
If you are using a webmodule for an ISAPI DLL or something that will cache an instance of a datamodule for use between different threads you will need a TIB_Session component.
For now, make sure the session component is first in the creation order for the form or module that it is on.
TDatabase
TransIsolation is only supported via the Isolation property of the TIBODatabase component. I have yet to figure out all the details on this item. For the time being it will be ignored while remaining in the Params property. You will need to manually set the isolation property of the TIBODatabase or TIB_Transaction that you will be using later on after the conversion.
TBDEDataset
CacheBlobs can be removed because right now IBO automatically caches all BLOB data. In the future I plan to allow selective criteria to try and keep excessively large BLOBs from using up all the system memory. It is possible to do a blanket invalidation of the buffers which will effectively deallocate the memory used by the BLOB cache if such a problem develops. This is done by calling the InvalidateRows method.
If you are using cached updates in order to implement non-standard ModifySQL, DeleteSQL and InsertSQL then you will still be able to implement these same customized DML statements. 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. Keep in mind that the TUpdateSQL component has been merged into the TIBOTable and TIBOQuery components so these properties will have to be manually copied over.
TTable
BatchMove method calls can be commented out and implemented later on using the TIB_Export or TIB_DataPump component or other means depending on where the data was being moved to or from.
Even though IndexName is supported, with SQL there should not be any direct name references to an INDEX. I suggest that you use the IndexFieldNames property instead. This allows a DBA the flexibility to add, modify and delete indexes without breaking the client application.
TQuery
No preparatory changes are required other than the ones already mentioned for the base class.
TStoredProc
No preparatory changes are required other than the ones already mentioned for the base class.
TField
No preparatory changes are required.
NOTE: It is necessary to change TBCDField to TIBOBCDField later on.
TUpdateSQL
This component has no direct equivalent in IBO. It's functionality is built right into the TIBODataset class. So, during the conversion you will take the values for it's properties and merge them into the dataset you are working with. There will be more said about this later on. For now just leave it alone.
