The new version of IBProvider v3.9 is delivered with the warranty(!) of stable performance within systems operating around the clock
Do you trust your access components for Firebird and InterBase as much as to allow them to be active without monitoring within software systems operating around the clock?
Maturity of a software system is defined by its ability to operate smoothly without monitoring for a sustained period of time.
You can close your eyes to the fact that:
- many “programs” have to be restarted several times an hour because of memory leaks, deadlock, as well as unexpected critical errors which close your application, say, ten minutes after you have typed an unsaved text.
- when working with large amounts of data you have to watch for several hours at the frozen application window, hoping that this report will nevertheless be read to the end, only to come early next day and see the “Out of memory” message instead of a ready analysis
The worst thing happens when the reason to these problems is not your code, but the selected access components for Firebird and InterBase.
Over 10 years of development and testing of access components within round-the-clock systems for processing large amounts of data, have taught IBProvider managers that mature access components must employ the “maximum client error tolerance” approach, instead of the common approach “this is your fault, you should have thought what you were going to transfer to your server”.
On the one hand, a usual driver can only be a layer between a database server and a client application and translate everthing that is transferred from the client to the server without any processing. This approach entails the problems described above:
- suspensions,
- memory overflow errors,
- critical errors leading to a loss of all unsaved data,
- conversion errors as well as the so-called “magic” errors of the server.
The maximum client error tolerance approach involves the following:
- A strategy of preventing any problem and repacking any client queries into the form compatible with InterBase and Firebird.
- Possibility of processing any amounts of data of any type (texts, videos, images, super arrays etc.).
- Automation of
routine developer operations such as:
- automatic description definition of instruction parameters.
- generation of update, delete, insert instructions based on select instruction.
- possibility of a batch execution of queries to a database in a single instruction (SQL-scripts).
- monitoring of memory overflow and roll-out of too large data into a separate SWAP-file on the local drive.
- Execution
of functions which are
not available on the server at the level of IBProvider.Including:
- nested transactions
- Boolean data types and GUID even for the most outdated server versions
- Automatic
detection of
the server type and its configuration:
- definition of the list of keywords reserved for the RDBMS.
- configuration of metadata loader.
- configuration of the parser of ODBC Escape Sequences.
- selection of nested transaction algorithm as well as a supported dialect.
- connection of algorithms optimized for a specific version of database server.
- and a whole range of individual settings which might still be unknown to IBProvider users.
- User-defined conversion of data types. While testing IBProvider we had to change many server scripts by our own ones, including the type converter.
So the new version of IBProvider v3.9 provides a fault tolerance which offers:
- New fail-safe algorithms for processing large arrays. For example — CHAR(30000) [-32000:32000,-32000:32000]. Optimized read/write operations for arrays.
- New fail-safe algorithms for processing 4 GB BLOB fields under 32-bit Windows.
- Correct support for 4-byte UTF8 symbols (processing of substitution symbols, extended size of WSTR-columns).
- Enhanced UNICODE_FSS support. Absolutely new scripts of conversion to UCS2 and vice versa.
- Patch for the error caused by .Net Transaction Scope and “Unsupported Isolation Level”. Now in case there is an UNSPECIFIED isolation level (-1), the provider will use an isolation level which is defined for the entire distributed transaction. Please note that by default TransactionScope uses SERIALIZABLE isolations. The other isolation level can be defined through TransactionOptions.
- Patch for the error caused by processing textual arrays and NONE code page.
- New 64-bit version assembly of IBProvider is implemented using the VS. Net 2010 compiler which provides a more efficient and smaller code. This is another reason to think about smooth transition to 64-bit applications.
We do not have time for manual testing of all working options of IBProvider that is why we conduct 1.44 million tests automatically
You might have noticed that IBProvider is regularly tested which helps fix critical errors which do not occur to a developer until they actually happen: data types, encodings, transactions, large amounts of data, multiple threads, maximum allowed values — all of this is to be automatically tested.
You would agree that it is better to foresee as many options as possible while texting access components instead of making your own collection of “what should not be done” while exploiting round-the-clock systems which are liable to terminate with a critial error without any explicit reason.
From June 11 through July 19, 2011, we conducted an intense multithread testing of IBProvider and Firebird:
- System: Vista x64, Q6600, 8GB, RAID10 (4xWD RE3 1TB)
- IBProvider: x64, v3.8.2.12727, compiler: VS2010
- Firebird: x64, v2.5.1.26308, SuperClassic, compiler: VS2008
- Tests: IBProvider Test System, 8 Threads.
Both the provider and the server passed 1.44 million different tests without any errors.
In conclusion, We would like to ask you the same question which was put up at the beginning of the article:
to allow them to be active without monitoring
within software systems operating
around the clock?
all the subsequent versions during one year absolutely FREE!