Here's the excerpt from the release notes pertaining to this release.

1/3/2012 Version 5.0.2 [Build 35]

I enhanced the getLitSafeStrPos() routine to be able to work with both single quotes as well as double quotes. Previously it only safeguarded against literals in double quotes. Thanks to Frank Reim for pointing out the need for this improvement.

I changed the way the filter expression is processed for case insensitive processing. Rather than use the operator UPPER() on the expression side, I just upper case whatever is there in the code, which is most likely a literal string value. This way the ability of indexes with the UPPER() operator can be used in an optimized way with the resulting filter expression that is sent to the server. Thanks again to Frank Reim for this improvement.

I made it so that when using a CTE (common table expression) with TIBOQuery/TIB_Query that the individual row CurrentCursor and BufferCursor internal objects produce valid SELECT statements to fetch individual rows. Previously it would just return an error message to check the KeyLinks. However, even with valid KeyLinks assigned it would still fail. The fix was to have an unprepared statement with a CTE to be properly seen as a SELECT statement. The IsSelectSQL property was returning false when it should have returned true.

1/3/2012 Version 5.0.2 [Build 34]

I added support for array columns to work through the AsString property.

1/1/2012 Version 5.0.2 [Build 33]

I added support for the SIMILAR TO clause in the Filter expression.

I made the new RETURNING clause for updates feature dependant upon whether the BufferSynchroFlags property indicates that the extra effort to keep the buffers synchronized is desired. This is to improve the performance of the baseline operations by eliminating potentially useless overhead. If all columns are represented in the RETURNING clause then the previous action to also re-fetch the record will be suppressed as that would be a duplication of effort. However, if your query has a column in it that doesn't have a corresponding column in the table, such as a correlated sub-query or an expression of some kind, the record re-fetch will still take place in addition to the row being returned from the update operation.

I made it so that when a connection is requested and a value for CharSet is not supplied that it will get the default character set of the database and use it as the connection CharSet property. If the database has NONE as the default character set then IBO will look for a new connection parameter called DEFAULT CHARSET and make use of it so that NONE will not be used as the connection CharSet. If this parameter is blank then IBO will now use UTF8 as the CharSet. This will show up in the value that is indicated by the connection's CharID property and it will appear in the CharSet property as well, but the connection's Params property will not have a CHARACTER SET value plugged into it. The CharSet property merely shows the CharSet used for the connection (FConnectedCharSet) while it is Connected = true. When disconnected the CharSet property will go back to showing blank to reflect what is in the Params stringlist for the connection.

I put in a way for a statement being executed via ExecuteImmediate() (such as when executing a TIB_Script) to be retried when it has a malformed character in it. For example, if you have an umlat in the comments of a stored procedure it can cause an error when it tries to store the source of the stored procedure into the UNICODE_FSS system table.

I fixed a couple bugs having to do with select statement using FIRST and/or SKIP. It was not working properly if you set the FetchWholeRows property to false. Now, if you have a FIRST and/or a SKIP token in your query then the FetchWholeRows property will be ignored. I also improved the RecordCount property so that it will take the FIRST and SKIP settings into consideration. If you have just a simple numeric value or if you are using just an input parameter then the RecordCount property will be successful. This is even true while the query is merely prepared.

In order to be Unicode compliant for internal settings of TIB_StringList param values, I had to replace the use of the GetCharValues() and SetCharValues() routines. I replaced them with stLitCriteria() and cvLitCriteria(), which are Unicode compliant. If you are directly manipulating the internal storage of TIB_StringList param settings you will need to watch out for the new format too. I have it still supporting the old format for the time being but it is considered deprecated. Both methods were able to co-exist together with the Unicode compliant method being defacto now.