New IBProvider — support of 49 code pages, ability to work without provider registering, prevention of memory leaks in Firebird client
The new IBProvider version:
- Support of 49 Firebird and InterBase code pages.
- Possible provider operation without registration in the system via manifest file.
- Prevention of memory leaks in Firebird client during library unloading.
- Specific errors have been fixed.
- IBProvider 188.8.131.5228
- IBProvider 184.108.40.20628
- IBProvider 220.127.116.1134 RC3
IBProvider v3 Release Candidate 3
Support of 49 Firebird and InterBase code pages
The new version of the driver supports all code pages of Firebird 2.1, including UNICODE_FSS, UTF8 and OCTETS binary data.
Connection of external conversion algorithms
The new icu_library initialization property defines the path to DLL-library that serves ICU character sets. You can take ICU library from Firebird 2.1 set: icuuc30.dll. You shall also copy auxiliary DLL: icudt30.dll.
With icuuc30.dll connection you will obtain the opportunity of working with CP943C and GBK. character sets.
IBProvider work without registering in the system
Access to Firebird and InterBase without installation of additional components in the operating system is topical for:
- WEB-applications on external hosting.
- Portable-applications connected to Firebird Embedded.
- Applications working with the database on the computer with limited user rights, without registering provider’s COM-component.
The information about COM-component is included into client’s application manifest file. This eliminates the necessity to register IBProvider in the registry. This feature is supported by all the versions of IBProvider Professional.
Firebird client unload
Memory leaks were registered during fbclient.dll unload in the Firebird client’s library prior to Firebird 2.5 version. To prevent leaks dbclient_lock_rules feature has been added to IBProvider that defines the fbclient.dll unload rule.
Possible values of dbclient_lock_rules:
0 — unload the client after disconnecting.
1 — unload the client together with the provider. Default behavior.
2 — do not unload the client’s library at all.
Keeping dll in memory reduces fbclient.dll upload/unload overheads and makes the application work faster.