IBO 5.x Full Source

What's new in IBO 5.x:

(Note: All bug-fixes will be mentioned in the Change Log only.)

Proper string support with the Delphi 2009+ unicode string being the default string type.

Note: I have not gone to the level of handling 4-byte code points in the UTF-16 strings. This level of compliance will come in a future revision. I am going to have to do a major overhaul of all of my string handling routines in order to check for surrogates that throw off the byte length vs. the character length ratio being consistent throughout the entire string. Currently, if the UTF-16 based string contains a surrogate, it could throw things off and produce errors. Thus, please do not consider 3 or 4 byte code points reliable for now.

Proper recognition and handling when working with UTF8 character set in the database.

Note: See warning above about code points with more than 2 bytes.

I enhanced cached updates with a new method UnskipUpdates so that you can pass through records in phases. In a first phase you can skip some records and then you can unskip them and go through another phase to handle them and then you can commit the updates. I also implemented the ability to acquire the TField.CurValue from the server for TIBOQuery and TIBOTable so that while you are resolving conflicts you can get access to what values are on the server. More details follow.

In the process of addressing the above mentioned issue, I decided to implement the TField.CurValue property. This property utilizes the connection's transaction used by the schema cache so it will always return the most recent committed changes regardless of what the transaction isolation of the query is. There is also a timeout associated with the cached records. If it sits for over 1 second (timeout can be configured) and the value is requested again then the server will be queried again and the previous data from the server will be replaced with the new version. In the native IBO components you can access the same information using the TIB_Column.CurValue property as well.

I have added a property called IB_TransForUpdates to the TIB_Statement class. Thus, all queries, etc. will be able to provide a separate transaction for all of the write operations it performs. If this property is left blank, the main IB_Transaction property will handle all reads and writes just as before. The one case where this is useful is if you want your updates to run under a read-repeatable (concurrency) isolation so that you will always be working with a consistent snapshot of the data in your trigger code. But, at the same time, you want your data queried from the server using read-committed isolation. This could not be achieved with IBO before now unless you manually did all of this on your own.

I scowered the internet and gathered together all of the various versions of the IBOAdmin components and merged them all into a single group of sources and am now including them as a supported part of IBO.

I enhanced the TIB_Monitor output to include transaction attributes when starting a transaction. I also added in client trace messages that accompany the transaction events so that you can tell the names of the objects in the monitor output that are in your application. I also made its string output handle special characters so that the actual contents of the string can be deciphered and so that the output wouldn't get mangled by special characters.

Removed deprecated IB_StoredProc.pas unit. The contents of this unit were put into IB_Access.pas.

I added TIBOArrayField so that TIBODataset can work with array columns.

There is a port of IBO to Free Pascal Compiler (Lazarus) that is ongoing. Inquire if interested.

There are some issues which may require some adjustments be made in your application:

I changed the default value of PreparedInserts for TIBODataset from false to true. This will have an impact on the behavior of columns that have a DEFAULT value declared on the server. With PreparedInserts being true by default this will prevent server defaults from being applied due to how Firebird/InterBase does not apply server defaults if the column is included in the Insert statement, even if it has the value of NULL coming in. Because of this I have added the property GetServerDefaults. What this will allow you to do is to have the query retreive the values for the default from the server and apply them at the time the record is being inserted. This has the benefit of seeing what that value is even prior to posting the record.

The XL SQL AddOn has been promoted to occupy the main source repository. This is a set of tools I contracted a developer to make so that people could have better integration with Excel spreadsheets. This set of components is still a work in progress.


Thanks munizf