Is there anything missing from IBX 2.3.0 that you believe should be added?
1st pict - IBX by -Rik-
2nd pict - original
You seem to be saying that the Firebird client library name should be a published property of the TIBDatabase class, and that there should be a separate default transaction for "updates". You have also noted when the "Browse" button is disabled in the TIBDatabase Component Editor.
1. The Firebird client library name as a published property of TIBDatabase
IBX already provides the FBLIB Environment Variable and the "OnGetLibraryName" callout function if you really need to customise the name/location of the Firebird Client Library (see section 3.3 of the Firebird Pascal API Guide for more information and the algorithm IBX uses to locate the Firebird Client Library). Under Linux, the LD_LIBRARY_PATH environment variable can also be used to identify non-standard locations. However, I do not agree with making the library name a published property of TIBDatabase, for the following reasons:
- Portability: the library name is different between platforms (e.g. fbclient.dll, libfbclient2.so, libfbclient.dyib,..) and in legacy versions (<3.0.0 of Firebird), the library name is different for the embedded version of Firebird.
- Also, the location can vary and so including the full path is a clear barrier to portability. Under Linux, each distro seems to put the client library in a different place, while under Windows, the location varies according to how it is installed and the Firebird version. IBX using a dynamic algorithm to locate the library. Under Linux, the loader gives it some help in looking standard locations, while under Windows it has to check various locations, looks up the Windows registry and will even try to use the "PATH" environment variable. You lose all of this if you hard code the location of the library.
- The library name is not a property of a single instance of TIBDatabase and is common to all instances. It is also common to Services API. If you did want to hard code the name and location of the client library then there would need to be a new component for this.
2. A Default Transaction for Updates
It is worth recalling that the purpose of the TIBDatabase.DefaultTransaction is no more than a user convenience. It does not have to be set to anything. If a DefaultTransaction is specified then when you assign a database to (e.g.) a TIBQuery, this transaction is automatically assigned to the same object. However, there is nothing to stop you changing this to a different transaction. You can have as many transactions as you believe necessary. If no DefaultTransaction is specified then all this means is that you have to expicitly assign a transaction to each (e.g.) TIBQuery as well as the Database connection.
If there was also a Default Update Transaction, I am just wondering what the semantic should be. With (e.g.) a TIBTable, the Select, Insert, Update, Delete and Refresh queries must all use the same transaction. That is because of transaction isolation and the need to maintain consistency within a single dataset. You could argue that the Update transaction is used for TIBTable and TIBDataSet while the read only transaction is used for TIBQuery - then what happens when an update object is assigned to a TIBQuery? If TIBDataSet and TIBQuery are on the same form then surely they should also use the same transaction and hence have the same view on the data? And what about TIBSQL and TIBStoredProc. It will always be dependent on the SQL or stored procedure name as to whether these should use read only or updateable transactions.
I really cannot see this feature as being useful.
3. The "Browse" Button.
This is always disabled unless the database connection is "local". It does not really make sense for a remote connection where it is not possible to browse for the database file.