Once the conversion is made to IBO based components and your application is compiling again there are some property settings that may need to be made to insure that your application will continue to function properly and perform its best. Once these properties are all set then your application should be functioning as it was prior to the conversion.
TIBODataset.KeyLinks property
In order for IBO datasets to be fully functional they require that some means of uniquely identifying each row be configured. One of the most significant settings you can make is to set the KeyLinks property of each dataset. This property is unique to IBO and required for some situations. In most all cases IBO can figure this out automatically but it is still better to control it manually.
For simple datasets of a single table that has a primary key IBO can figure out the KeyLinks automatically. However, if you set it manually then you will save the system from having to execute a query to figure this out. Some queries may need to have the primary key columns included in the select list too because if you need them in the KeyLinks you need them in the SELECT as well.
IBO used to throw in the columns of the primary key whether they were in the select list or not. This caused an error if they were not in the select list. I have now made IBO KeyLinksAutoDefine behavior smart enough to add only KeyLinks that are valid for the query. If you are relying on this, it may prove beneficial, especially now that IBO is going to be silent on the issue, to review your application for areas where including the primary key columns may prove beneficial.
In more complex cases where IBO cannot deduce which columns constitute the key columns for the dataset, it will use the InterBase DB_KEY or an arbitrary integer value if a DB_KEY cannot be obtained. In these cases IBO's activity is limited to what it can do with the dataset and it may be unable to perform certain functions automatically, such as delivering a live result set. In most cases it simply reverts to become a more client-centric tool, doing things in the client data instead of using its knowledge of the keys to offload work to the server.
KeyLinks is simply a list of columns in the dataset that constitute what uniquely describes each record *potentially* selected into the dataset. If there is a single column in a primary key then simply put this column in the list. If there are two columns then place each column on its own line in the list. It's a good idea to get into the habit of prefacing column names with their table name and a period. I call this the full field reference.
Don't confuse the KeyLinks columns with the "Key" columns defined in the IndexFieldNames property. The purpose of KeyLinks columns is to uniquely identify each row so that special operations can be performed with them, not to determine which columns the dataset is ordered by.
TIBODataset.JoinLinks property
If you are using SELECT statements that include multiple tables and the criteria to join those tables are in the WHERE clause instead of the JOIN clause, then you need to remove them from the WHERE clause and provide them as entries in the JoinLinks property.
In order for IBO to do some of the things it needs to internally it must be able to distinguish between normal WHERE clause material and that which is participating in the JOIN.
If this is not done and/or the KeyLinks property is not set correctly, you will most likely see a "Multiple Rows in Singleton Fetch" error pop out of the blue. This means either the KeyLinks and/or the JoinLinks properties were not setup correctly. In short, the SQL it put together only expects to receive a single row but the server sent it more than one row unexpectedly. This is not a bug in IBO but a problem in your application that must be solved.
Make sure the BDE is removed
Once all of the BDE based components have been converted to IBO based components it may still be necessary to clean up the Uses clause in all of your unit files. Unless you actually test it on a machine without the BDE you may find that your application still requires that the BDE be installed on the client machine if just one reference to a BDE unit is remaining.
So, as a precautionary measure, test the EXE on a workstation that does not have the BDE installed. If this is not done then it is still possible to have the BDE's code linked into your EXE. Removing these unit references will also reveal additional pieces of code that are not yet fully converted.
You will of course still need the IB Client installed as a minimum in addition to your EXE.
