What is IB Objects?
IB Objects is the most powerful toolbox available for developing client and service applications for InterBase/Firebird in Delphi and Borland C++Builder without the BDE, ODBC or any other middleware.
IB Objects provides more than 80 components for use with 32bit Delphi and C++Builder. The "native IBO" classes require only a Desktop Developer edition. Professional editions of these products are required only if you need to develop with the TDataset-compatible classes.
Why was IB Objects needed?
Generic client-to-database layers like the BDE, ODBC, dbExpress and ADO hide most of the capabilities of transactional database engines, flattening connectivity to a generic "lowest common denominator". Powerful server databases like InterBase/Firebird and Oracle are made to conform to the behaviors of desktop databases like Paradox or dBase. It takes heavy layering of client and middleware driver code between the user and the database to accomplish this flattening, while disabling essential capabilities of the server databases' engines.
Since everything in InterBase/Firebird happens inside transactions, this approach essentially kills most of the benefits of using client/server for networking mission-critical applications.
IBO cuts right through all this and connects its data access objects directly to the application programming interface (API) of the InterBase/Firebird engine. Your application gets full and complete access to InterBase transaction capabilities - multiple concurrent transactions for a single connection and transactions that span multiple databases with two-phase commit. Four levels of concurrency isolation become available and, with them, the full, flexible range of controls that InterBase provides for optimizing transaction life and resolving lock conflicts.
What about other component suites?
Other component suites can provide direct-to-API connectivity but they do so at the cost of developer control over the logical aspects of transaction-based data processing. They are bitten by the hand that feeds them. In order to implement access to the physical capabilities of the transaction engine while remaining locked into the memory dependency of the VCL's TDataset, they sacrifice the considerable benefits the BDE provided in the way of task management.
Why choose IB Objects?
From the start IBO freed itself from the restrictions of TDataset and its limiting, local database oriented memory model. From the primitive level of TComponent forward, its classes are built on a foundation dedicated solely to how an object interface needs to interact with InterBase/Firebird with greatest effect and efficiency. Along the way, IBO has succeeded in emulating and improving on the logical task environment provided by the BDE to the degree that a developer can choose to be unconcerned with the physical transaction altogether.
An important point of differentiation from other direct access components is IBO's track record of four full, industrial-strength releases and nearly five years of consistent development, spanning all 32-bit Delphi and C++Builder releases and all versions of InterBase/Firebird from InterBase 4.x up. IB Objects won the Delphi Informant Reader's Choice award for Best Database Connectivity product in both 2000 and 2001.
7/17/2018 Version 5.9.9 [Build 2784]
- I fixed a bug when handling a Filter setting with an EXISTS() clause with something AND'd with it.
- I fixed a problem with the UpdatesPending property to tell how many cached updates are waiting to be applied.
- I fixed a bug in the logic that compares the values of single or double floating point variant values. I wasn't properly taking the Unassigned state into account when comparing values. It was taking one of them as Unassigned and one of them as 0 and deeming them equal when they aren't.
- I fixed a bug where a cached inserted record was getting removed from the buffer when calling InvalidateRowNum() or Refresh().
- I made the TIB_Session.CheckForReservedTokens property published.
- I added TIBOBytesField and TIBOVarBytesField in order to work around a problem with the Delphi classes they inherit from. It was having issues when converting the bytes data to data represented as string data. I had to do this to make older versions of Delphi consistent with newer versions of Delphi. When storing raw bytes data in a widestring it actually uses the double byte character to store two bytes of the raw data.
- I enhanced the behavior of the JoinLinks property so that if it is changed it will cause the query to be unprepared and prepared again so that the impact to this property will be properly distributed to all of the internal cursors of the TIB_Query and TIBOQuery components.
- I improved TIB_Query and TIBOQuery so that if it was prepared but the SQL has been invalidated, by calling the InvalidateSQL method, and the Open method is called it will detect this and do a reprepare prior to opening the query.
- I improved the process of handling the OnNewRecord event and the appending of records. In some cases it was possible for the CheckBrowseMode method to cause things to re-enter the posting of the new record.
- I fixed a problem with bsfBeforeEdit and bsfAfterInsert BufferSynchroFlags settings. In some cases it wasn't synchronizing the values in the record as it should.
- I improved datatype conversion between double datatype and the timestamp datatype.
- I improved the behavior of getting the default value of columns so that it will handle NULL values more appropriately. I also improved the behavior of GeneratorLinks so that it will go ahead and apply a new value from the generator if the column has the value of a declared default value instead of only doing so when it is a NULL value.
- I enhanced the behavior of the ordering columns in the TIB_Grid control. It now handles the use of OrderingLinks that have different columns than are in the OrderingItems as it used to before the recent changes enhancing the ordering mechanisms to use up to 3 columns in the horizontal dataset refinement feature.
- I enhanced the TIB_CGrid control so that it will behave better when a dataset is navigating through records and the EOF or BOF position is hit. The control's navigation used to take the dataset to EOF or BOF and then it would scroll back. Now it recognizes that it would go to EOF or BOF and it simply doesn't scroll away from the current record.