Hello Jason,

installed build 36i and it looks like that all my reported problems are
sorted out.

Thanks!

Regards,
Thomas

> I also made some improvements to the installer that could possibly enable it to work for those who are having it fail on them.
>
>
> Here are the release notes since the last announced release:
>
>
> 1/23/2012 Version 4.9 Release 14 [Build 36i]
>
> I improved the new Screen.Cursor handling algorithm. The screen cursor was going invisible in some cases.
>
> I fixed a painting problem with the button bars for Delphi 2009, 2010 and XE.
>
> 1/20/2012 Version 4.9 Release 14 [Build 36h]
>
> I fixed a bug in the script parsing logic that detects a TRIGGER or STORED PROCEDURE statement in order to allow the semicolon to be the statement terminator without a problem. Thanks to Sean Palmer who pointing out this problem and helped me to fix it by sending a sample app.
>
> Thomas Steinmaurer pointed out a problem with the component editor for the TIB_Connection. If you made a connection to a database then it would reflect the ForcedWrites and ReservePageSpace status in their respective checkboxes. But, this had the effect of storing a setting other than just leaving it to the default setting. Thus, applications would try to make set it to true or false when a connection was requested instead of just leaving it alone. This problem became more clear when a non-SYSDBA/OWNER user attempted to connect and failed with an error due to lack of permission.
>
> Thanks to the suggestion of Carlos Cantu, I implemented a way to avoid the screen cursor flickering so much when performing quick operations repeatedly. If you have a TIB_Session with UseCursor set to true and the TimerInterval is set to something above zero then you will be able to notice the screen cursor avoiding flicker. It relies on the session's internal timer to see if there is no more active work going on. If enough time has elapsed, the screen cursor will be returned to normal. There is some fine tuning of the session's timer interval so that the screen cursor will behave in a consistent and accurate manner. I also added the RestoreCursorTicks property so that you can fine tune the timing involved in this new feature.
>
> I adjusted the behavior of CheckTransaction() so that when preparing statements it will make use of the transaction of the schema cache, which is a read-committed and read-only transaction. This makes IBO more friendly for garbage collection as well as more precise when working with tiConcurrency/tiConsistency isolation level because it won't prematurely start the physical transction that locks in your snapshot view. Credit also goes to Carlos Cantu for helping with this.
>
> 1/19/2012 Version 4.9 Release 14 [Build 36g]
>
> I fixed a glitch in the TIBODataset handling of TParams when the SQLWhere clause is changed while the query is prepared. If a new parameter is included in the SQLWhere, IBO was not adding in a new TParam object. I now cause an immediate re-prepare when the SQLWhere is modified so that the TParams will be repopulated immediately as well.
>
> I finalized the support for DMLCaching to be included in the IBODataset classes.
>
> 1/18/2012 Version 4.9 Release 14 [Build 36f]
>
> I fixed the case where DMLCache events being received while in insert mode could lead to a needless exception being raised. It will now set a flag so that when the Insert is posted it will process the DMLCache event. In the future I will try to have it process the event even while in Insert mode without interfering, if at all possible.
>
> I surfaced the DMLCacheFlags property to the TIBODataset class so that TIBOQuery and TIBOTable can make use of the DML caching capabilities. I also surfaced the GetServerDefaults property to TIBODataset as well.
>
> I adjusted the timing of when a post of a dataset will cause the transaction to be activated such that it will happen (by default) after the AfterPost event has been processed. This allows other actions that need to take place inside the AfterPost event to be included in the processing of the post. Note: It is also acceptable if you want the transaction activated to go ahead and call it directly in the AfterPost event and then it won't be called subsequently. This is so because I use a newly added property called ActivateSequence. It is a simple counter that increments each time Activate is called and rolls over again as needed. Thus, I can distinguish if the Post yet needs to be activated when all of the events dealing with the post are completed and then I Activate the transaction if it has not yet been Activated since the post actually took place on the server.
>
> 1/17/2012 Version 4.9 Release 14 [Build 36e]
>
> I fixed a glitch in the IsEmpty() method from my recent enhancement to it. I added it to the regression testing so that it will remain solid in its expected behavior.
>
> I discovered that using CacheStatementHandles can be problematic so I have set its default value to false until I get to the bottom of what caused a glitch in someone's application. It could actually be an issue with Firebird as well. But, things will stay more clean if a new handle is acquired more regularly instead of using the same handle over and over again for any number of statements.
>
>
> Jason
> www.ibobjects.com
>
>
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more ! Yahoo! Groups Links
>
>
>