Lazarus
Announcements => Third party => Topic started by: tonyw on April 16, 2018, 04:31:37 pm
-
MWA Software is pleased to announce that release 2.3.0 of IBX for Lazarus is now available for download from https://mwasoftware.co.uk/ibx. All users are recommended to upgrade to the new release. Please read the changelog before upgrading.
IMPORTANT: the source code tree has been re-organised for IBX 2.3. Please remove all previous copies of the IBX source code tree before installing this release.
This release introduces the IBXServices unit. The IBXServices unit is a re-architectured update of the IBServices unit providing what is intended to be a clearer and easier to use set of IB Services components. See Chapter 10 of the IBX User Guide for more information and the guide to "Firebird Service Management Using IBX". The legacy services components are still available and provided in a separate package. There is no need to update working applications using the older versions except for an additional package dependency.
The update also includes several improvements/additions to TIBExtract and bug fixes to date.
-
For information related to this site, what is enough to help increase knowledge?
My understanding of your question is that you are asking how do you find out more about IBX, especially at the tutorial level.
IBX for Lazarus is a fork of the original InterBase Express (IBX) that is provided with Delphi. As such, much of the same tutorial level information on the Internet applies to both component sets. Additionally, IBX for Lazarus comes with a large User Manual that is intended to be comprehensive. This is also supplemented by a Guide to using IBX for Firebird Database Management and a separate User Manual for the underlying Firebird Pascal API.
To use IBX effectively you will also need to have a working knowledge of the Firebird Database Management System and SQL. The Firebird SQL website (https://www.firebirdsql.org/) is a good starting point for this. You also need to have an understanding of the TDataSet Model and how it is used with data aware controls to build database applications. However, you can start with very little knowledge of these and then build up.
IBX is a bridge between the Delphi/Lazarus TDataSet model and a Firebird Database and one which is specifically tuned to work with Firebird and to be optimal in its use of Firebird.
-
Unfortunately, MWA Software is unable to directly test Darwin (OSX) builds of IBX and instead relies upon community support for testing under Darwin. As a result, a Darwin only include file was included in release 2.3.0 that contained a syntax error preventing compilation due to a missing semi-colon. The file affected is ibx/fbintf/client/include/uloadlibrary.inc. The missing semi-colon is on line 50.
Darwin users should either edit the affected file or may obtain an updated archive from:
https://svn.mwasoftware.co.uk/viewvc/public/ibx/trunk/?view=tar
-
Thanks for your grandiose work. But your components have very big shortcoming. The user can't specify any localization of fbclient.dll/fbclient.so in TIBDatabase.
This defect is eliminated in IBX by -Rik- aka Yuri Kopnin. He has taken one of the previous versions of your component as a basis. Source codes of a component can be found here (http://visual-t.ru/files/ibx.7z).
I wanted to ask to correct your component in this way if it is possible. Thanks.
-
Thanks for your grandiose work. But your components have very big shortcoming. The user can't specify any localization of fbclient.dll/fbclient.so in TIBDatabase.
This defect is eliminated in IBX by -Rik- aka Yuri Kopnin. He has taken one of the previous versions of your component as a basis. Source codes of a component can be found here (http://visual-t.ru/files/ibx.7z).
I wanted to ask to correct your component in this way if it is possible. Thanks.
zoltanleo,
I am finding it difficult to pin-point the change you are requesting. The updated IBX you posted is clearly from a very old version - and the changelog is missing which makes it difficult to find the original archive with which to compare it with. The only changes I could identify were in the area of identifying Firebird character sets and Boolean support.
The version you posted appears to pre-date FPC 3.0.0 support and the introduction of ANSI codepage support into IBX. Since IBX 1.3.2, IBX has supported all Firebird Character sets with automatic transliteration into whichever character set you are using internally (ideally UTF8 - but all other Firebird character sets should work). Boolean was added to IBX in 2.0.0 with the introduction of full Firebird 3 support.
Is there anything missing from IBX 2.3.0 that you believe should be added?
-
Is there anything missing from IBX 2.3.0 that you believe should be added?
1st pict - IBX by -Rik-
2nd pict - original
-
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.
-
for the following reasons...
Your component uses static binding of client library IB/Firebird. It forces the developer to place these libraries only in strictly certain directories of an operating system. Such application won't be able sometimes to function on OS where several copies of the FB server are started. Because the end user will have no opportunity to specify the "correct" library during connection to the server.
For this reason more convenient and functional FIB Plus components for Delphi have been created. Unfortunately now these components don't develop officially. But from development some enthusiasts (source (https://github.com/madorin/fibplus)) continue (perhaps, illegally).
The possibility of the indication of the second of transactions is desirable, but not priority (in my opinion). I will agree with your arguments.
-
for the following reasons...
Your component uses static binding of client library IB/Firebird. It forces the developer to place these libraries only in strictly certain directories of an operating system. Such application won't be able sometimes to function on OS where several copies of the FB server are started. Because the end user will have no opportunity to specify the "correct" library during connection to the server.
In development, I may have different versions of Firebird available - Firebird itself does help here for various reasons - but it is still possible. Why is the FBLIB environment variable or on the "OnGetLibraryName" callout not suitable for these cases? OnGetLibraryName could even put up a dialog or read some configuration file.
It would be possible to add an optional component to IBX that can override the built-in libraryname and if there is demand for this then I can consider adding it. But in practice this would simply hook into the OnGetLibraryName handler.
For this reason more convenient and functional FIB Plus components for Delphi have been created. Unfortunately now these components don't develop officially. But from development some enthusiasts (resource (https://github.com/madorin/fibplus)) continue (perhaps, illegally).
As long as the original IBX licence conditions (set by Borland/Imprise) continue to be observed, there is no problem in forking the code or making patches available.
-
for the following reasons...
Your component uses static binding of client library IB/Firebird. It forces the developer to place these libraries only in strictly certain directories of an operating system. Such application won't be able sometimes to function on OS where several copies of the FB server are started. Because the end user will have no opportunity to specify the "correct" library during connection to the server.
You obviously missed this:
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).
The point is -- the FB client library location does not belong to TIBDatabase, it is shared among the connections. It does not mean that you can not set it programmatically -- you can.
From the Firebird Pascal API Guide:3.3.4.2
The OnGetLibraryName Event Handler
The
OnGetLibraryName
event handler is defined in the IB unit and has the type:
TOnGetLibraryName = procedure(var libname: string);
If this event handler is set before the first call the the Firebird Pascal Client API then it is called
and should return the absolute or relative path, the pathname of the Firebird Client library. The
fbintf
loader will try to load this library. If this fails then no further attempt is made to load the
Firebird Client Library. If the event handler returns an empty libname then it is ignored
@tonyw:
I didn't find if it is possible to unload the already loaded library programmatically. Is it possible, so that we can switch to another (for any reason) during the programme execution?
-
@tonyw:
I didn't find if it is possible to unload the already loaded library programmatically. Is it possible, so that we can switch to another (for any reason) during the programme execution?
This one more reason for which I ask to add this public property. As compromise option, I wanted to suggest to enter a name of library from FBLIB by default there. Use of event OnGetLibraryName generates a lot of excess code :(
-
@tonyw:
I didn't find if it is possible to unload the already loaded library programmatically. Is it possible, so that we can switch to another (for any reason) during the programme execution?
In principle, that is not too difficult to arrange - although you must close all databases and services API connections as well, as unloading the library would close all connections to the server and commit/rollback any open transactions. The way the code is written, you could readily add a procedure to IB.pas that set the internal variable FFirebirdAPI to nil. However, that would not necessarily unload the library immediately. This would only happen once all connections are closed.
-
@tonyw:
I didn't find if it is possible to unload the already loaded library programmatically. Is it possible, so that we can switch to another (for any reason) during the programme execution?
This one more reason for which I ask to add this public property. As compromise option, I wanted to suggest to enter a name of library from FBLIB by default there. Use of event OnGetLibraryName generates a lot of excess code :(
Please note that if you do want to use the FBLIB environment variable then, as documented, you have to set AllowUseOfFBLib := true. The AllowUseOfFBLib variable is defined in IB.pas and defaults to false. This is a security control and is to avoid production programs becoming hijacked by a bogus client library.
-
Please note that if you do want to use the FBLIB environment variable then, as documented, you have to set AllowUseOfFBLib := true. The AllowUseOfFBLib variable is defined in IB.pas and defaults to false. This is a security control and is to avoid production programs becoming hijacked by a bogus client library.
I don't want to use FBLIB because I don't want to force the user to use terminal or cmd.exe to add a way to necessary libraries.
It is much more convenient to me to allow the user most to choose clients library because several FB servers of different versions can be at the same time let into OS.
I am sorry that at present your component has limited functionality. It limits his further. I hope that you will listen to wishes of those who will be glad to use your useful product.
-
Please note that if you do want to use the FBLIB environment variable then, as documented, you have to set AllowUseOfFBLib := true. The AllowUseOfFBLib variable is defined in IB.pas and defaults to false. This is a security control and is to avoid production programs becoming hijacked by a bogus client library.
I don't want to use FBLIB because I don't want to force the user to use terminal or cmd.exe to add a way to necessary libraries.
It is much more convenient to me to allow the user most to choose clients library because several FB servers of different versions can be at the same time let into OS.
I am sorry that at present your component has limited functionality. It limits his further. I hope that you will listen to wishes of those who will be glad to use your useful product.
Thank you for your comments. I do respond to requests from users for requests for new features. In the meantime, have you considered writing a simple OnGetLibraryName handler that puts up a dialog giving a drop down list of alternative paths and which also allows the user to enter their own path. The dialog can then return the selected library path - perhaps also testing to ensure that the selected library exists in order to give the best feedback to your user.
-
I do respond to requests from users for requests for new features.
Am I to understand that you will add this functionality to the component? :)
-
I do respond to requests from users for requests for new features.
Am I to understand that you will add this functionality to the component? :)
What I will probably do is to add an example of how to select the FB library and do it so that the code can be easily copied and pasted into your project. Although if I can think of a better way to do this, then I will.
-
A small suggestion:
As described in Firebird Pascal API User guide (section 2.5), on top of IB.pas, there are two definitions:
{$DEFINE USEFIREBIRD3API}
{$DEFINE USELEGACYFIREBIRDAPI}
which say that the ibintf package will be compiled with support for both legacy api and new api.
Now we can change this by commenting out one of these if we do not intend to use it.
Although commenting out a line is quite simple, I just prefer not to change the original sources. So I'd suggest you change these lines to:
{$IF NOT DEFINED(USEFIREBIRD3API) AND NOT DEFINED(USELEGACYFIREBIRDAPI)}
// only if none of this is already defined, define both:
{$DEFINE USEFIREBIRD3API}
{$DEFINE USELEGACYFIREBIRDAPI}
{$ENDIF}
This way, I will be able put -dUSEFIREBIRD3API in my project's compiler options (http://wiki.freepascal.org/IDE_Window:_Compiler_Options#Custom_Options) and my project will be compiled with fbintf library supporting new api only. If none of these options is added to the project options, both will be included.
In my opinion this is cleaner way than changing the sources.
-
A small suggestion:
As described in Firebird Pascal API User guide (section 2.5), on top of IB.pas, there are two definitions:
{$DEFINE USEFIREBIRD3API}
{$DEFINE USELEGACYFIREBIRDAPI}
which say that the ibintf package will be compiled with support for both legacy api and new api.
Now we can change this by commenting out one of these if we do not intend to use it.
Although commenting out a line is quite simple, I just prefer not to change the original sources. So I'd suggest you change these lines to:
{$IF NOT DEFINED(USEFIREBIRD3API) AND NOT DEFINED(USELEGACYFIREBIRDAPI)}
// only if none of this is already defined, define both:
{$DEFINE USEFIREBIRD3API}
{$DEFINE USELEGACYFIREBIRDAPI}
{$ENDIF}
This way, I will be able put -dUSEFIREBIRD3API in my project's compiler options (http://wiki.freepascal.org/IDE_Window:_Compiler_Options#Custom_Options) and my project will be compiled with fbintf library supporting new api only. If none of these options is added to the project options, both will be included.
In my opinion this is cleaner way than changing the sources.
I can see the sense of that and will look into adding the idea.