| Subject | New release of IB Objects 4.9.14 (Build 28a) (Important to get this release!!!) |
|---|---|
| Author | kylixguru |
| Post date | 2011-12-10T07:03:42Z |
After a bit of a battle with getting my installer to work properly, I'm now ready to make the next release of IBO.
There have been some very important bug fixes in this version. I found a flaw in the logic of encoding and decoding BLOB input parameters. As a result of this, it is possible that characters have been stored incorrectly in your database. Fortunately, for those using Firebird 2.5, there was the "malformed string" check that alerted when this problem was happening.
Also, as a means to avoid extra parsing of your statements, when using input parameters in IBO it is a good idea to use the table name and the column name separated by a period so that when I parse out the name of the parameter it can be associated with an actual table.column in the database and then I will use it's charset information to handle that input parameter correctly. As it is right now, if the table name does not qualify the parameter name I will parse the insert, update or delete statement in order to grab their charset details. (Of course this is only relevant when Charset NONE is used for the connection Charset. This puts the burden of storing the bytes into the database according to the actual type of the column since the Firebird engine won't do any transliteration.)
I also fixed a flaw having to do with the Lookup() method. If you are searching on columns and passing in NULL values it wasn't properly responding to them which could have resulted in failed searches.
I fixed a bug in the IB_Currency edit control where the negative sign was getting scraped off if it was -0.nn.
There was a problem with C++ Builder not handling a function that returned an array. I rewrote the function to be a procedure that has an "out" parameter and then it worked just great.
Also, I was able to work with Vlad Khorsun on fixing a bug in Firebird, which is now working correctly in the latest build of FB 2.5.2. It had to do with the EXECUTE BLOCK statement being executed via the TIB_DSQL statement when output was returned. For some reason it was automatically opening a cursor on the server and leaving it open. This caused a subsequent attempt to execute that statement to error out with a 'cursor is already open' message. I was able to put a temporary work around so that it will detect this error, close the cursor and then execute it again. But, with the fixed version of Firebird there won't be an inappropriate error.
Please see the release notes for more details about other changes.
Kind regards,
Jason Wharton
www.ibobjects.com
There have been some very important bug fixes in this version. I found a flaw in the logic of encoding and decoding BLOB input parameters. As a result of this, it is possible that characters have been stored incorrectly in your database. Fortunately, for those using Firebird 2.5, there was the "malformed string" check that alerted when this problem was happening.
Also, as a means to avoid extra parsing of your statements, when using input parameters in IBO it is a good idea to use the table name and the column name separated by a period so that when I parse out the name of the parameter it can be associated with an actual table.column in the database and then I will use it's charset information to handle that input parameter correctly. As it is right now, if the table name does not qualify the parameter name I will parse the insert, update or delete statement in order to grab their charset details. (Of course this is only relevant when Charset NONE is used for the connection Charset. This puts the burden of storing the bytes into the database according to the actual type of the column since the Firebird engine won't do any transliteration.)
I also fixed a flaw having to do with the Lookup() method. If you are searching on columns and passing in NULL values it wasn't properly responding to them which could have resulted in failed searches.
I fixed a bug in the IB_Currency edit control where the negative sign was getting scraped off if it was -0.nn.
There was a problem with C++ Builder not handling a function that returned an array. I rewrote the function to be a procedure that has an "out" parameter and then it worked just great.
Also, I was able to work with Vlad Khorsun on fixing a bug in Firebird, which is now working correctly in the latest build of FB 2.5.2. It had to do with the EXECUTE BLOCK statement being executed via the TIB_DSQL statement when output was returned. For some reason it was automatically opening a cursor on the server and leaving it open. This caused a subsequent attempt to execute that statement to error out with a 'cursor is already open' message. I was able to put a temporary work around so that it will detect this error, close the cursor and then execute it again. But, with the fixed version of Firebird there won't be an inappropriate error.
Please see the release notes for more details about other changes.
Kind regards,
Jason Wharton
www.ibobjects.com