Danny Thorpe and Tagawa-san are working on an Update 2 for Delphi 2005

Here's the direct quote:

Actually, I'm knee deep in niggly bug fixes in the compiler, RTL, and
VCL for the next D2005 update. Tagawa-san is, too.

Read more @ http://www.lemanix.com/nick/archive/2005/01/28/1632.aspx

SAS is the company that comissioned the Vulcan port of Firebird

My name is David Shamlin; I am with SAS Institute, Inc (http://www.sas.com/). SAS is the company that comissioned the Vulcan port of Firebird. We are a business and analytic intelligence software vendor.



A year and a half ago we identified a business need to incorporate relational/ACID transaction storage capabilities into our platform bundle and decided to pursue an open source database solution that met our requirements. We chose Firebird because it supported an embedable database engine and implemented many of the SQL semantics our consumers need. Because our software platform runs on a number of 64-bit SMP operating systems, our first order of business was to create a Firebird port to one of these systems and introduce modest (i.e., multiple user requests executing in parallel) multi-threading capabilities to the engine. We entered into a partnership with IBPhoenix and with Paul Beach's help acquired the services of Jim Starkey to do much of the heavy lifting on the project for us.



In December of last year, Jim (with Ann's help) finished the initial phases of this work which has come to be refered to as the Firebird Vulcan project. During that time, we also had the opportunity to address some minor JDBC issues with Roman and discuss testing strategies with Pavel. Currently, SAS has three developers and a DBMS product specialist working full time with the Vulcan source. A couple of additional individuals are contributing on a part time basis to additional porting and testing efforts. We have an initial port to z/OS completed, and I hope to initiate ports to a couple more 64-bit Unix/Linux systems in the first quarter of this year.



SAS's intent since the beginning of the project has been to contribute to the Firebird open source project and continue to be an active supporter through direct development and possibly commissioning further coding projects in the future. Since Jim turned over his final work to us in December, we have accumulated a series of source code changes that address some bugs we've uncovered through our testing. At this point, we're interested in committing these changes to the new Vulcan repository on Sourceforge and would like to enter into a dialog with the Firebird project administrators on how we can most effectively accomplish that.



We're pleased with the results we have achieved with Firebird/Vulcan to date and excited about becoming an active participant in the Firebird project. I trust the community at large also sees the value inherent in Vulcan and will welcome SAS's contribution. We look forward to the opportunity to collaborate with the team and getting to know others involved with Firebird better.



I can be reached for direct follow up at david.shamlin@sas.com   and will continue monitor this mail list in case the group wishes to have a more public discussion.



Thanks for your attention -- David

--

R&D Director, SAS Institute, Inc

The Code Project - Embedded Firebird: Full-Featured Embedded Database with 2 MB Runtime

Firebird is an database with 20 years of history, full set of features (including transactions, stored procedures, hot-backup, excellent scalability, etc.) and a friendly open source license. It is an overlooked but compelling alternative to Microsoft Jet and Microsoft MSDE 2000/SQL Express 2005. Let's take a look how it can be used embedded in your desktop application. What makes Embedded Firebird ideal for embedding:

• The embedded runtime is <>
• The database file (it's just a single file) can have any name and extension. You can associate the extension with your application.
• The migration to a standalone server couldn't be easier. Just copy the database file to the server and change a connection string on your client.

Read more @ http://www.codeproject.com/useritems/EmbeddedFirebird.asp

Vulcan Merge

The strategy to merge Vulcan and Firebird 2.0 to form Firebird 3.0 will
probably be gated by a single central question: Will Firebird 3.0 use
the Vulcan provider architecture.

Firebird 2.0 consists of two main pieces: A client library and a server
executable (some platforms have an embedded engine packages as a plug
replacement for the client library). The client library contains a
Y-valve front-ending the remote interface. The server executable
contains the server code, the Y-valve, and an engine.

In the Vulcan provider architecture, the client library (Firebird.dll
or libfirebird.so) contains only the Y-valve. During the database
attach operation, the Y-valve, under control of a configuration files,
tries to load provider modules from an ordered list until one is able to
successfully attach the database. Vulcan currently has providers for
the engine, the remote interface, and a gateway to legacy Firebird and
Interbase. When the ODS is changed, Vulcan gets another engine
provider, retaining the old shared libraries (buildable only from a CVS
tag) for backwards compatibility. Finally, in Vulcan, the server is an
executable linked to the same client library as ordinary client programs.

The provider architecture has a number of advantages. One is the
ability to perform rolling upgrades. In Firebird 2.0, there are two
ways to provide access to databases with different ODSes. One is to
have the single engine support a variety of ODSes. The other is for the
user to balance two (or more) Firebird installs on the same system. For
former is constraining on development, leading to unnecessarily complex
code to straddle versions, while the latter shift the burden to the
user. The Vulcan provider architecture, on the other hand, allows us to
release a new engine version as a new provider, leaving the existing
engine(s) in place, with a tweak of the core configuration file. This
allow a single program to attach simultaneously two databases of
radically different ODS versions, for a single installation to straddle
versions, and for production and development versions to coexist on a
single system.

The Firebird Y-valve, on the other hand, is hard linked to a fix set of
subsystems managed with conditional compilation.

A further complication is that while the Vulcan Y-valve requires that
each provider be thread safe, the Firebird Y-valve assumes its
subsystems are not, initiating THREAD_ENTER/THREAD_EXIT synchronization
before every subsystem calls, leading to tight integration between the
Firebird Y-valve and engine. Imposing the Vulcan provider architecture
on Firebird 2.0 breaks the division of work between the Firebird why.cpp
and jrd.cpp, and forcing the same global reorganization I had to do for
Vulcan.

The provider architecture is, perhaps, the most important aspect of
Vulcan, providing a clear, clean mechanism to manage change. And change
is the one thing we can be certain of.

Vulcan Priorites

Vulcan's highest priority is Firebird 2.0 coexistence. Vulcan and
Firebird 2.0 should be serially shared database files. To this end,
Vulcan needs to bring its ODS up to that of Firebird 2.0. The Vulcan
ODS is based on a bastard snapshot of the Firebird 2.0 development tree
a year ago last December. To the best of my knowledge, and I may well
be wrong, the major difference is index structure. Vulcan desperately
needs Arno's extended indexes. The conversion shouldn't be difficult --
btr.cpp was lightly touched -- and while the page cache manager has been
heavily rebuilt, the macros used for interface has been redefined. The
second part of coexistence is making sure that Vulcan and Firebird 2.0
don't trip over each other. For better or worse, the requirement to
support fine granularity threading dictated a change to the lock manager
format, so actually sharing a database between Vulcan and Firebird 2.0
is out of the question. We should, however, make sure that Vulcan uses
a different lock file with an appropriately different header. I think
we also need to solve, for once and all, a strategy that ensures that
two engines never try to shared a database file using different lock
managers. I'll make this the subject of a different post.

I think the second priority is fixing the Linux/Unix build procedure.
The procedure in place is strictly ad hoc for my personal convenience.
It needs to support building outside of the source directories,
differential build for production releases, and support for hybrid 32/64
releases. The dependency on autoconfig is definitely a problem for
platforms that support both 32 and 64 bit executables. Buildgen is
design to generate "stuff" from component specific Visual Studio 7
project files. Right now it generates complete makefiles. I could also
be used in a more limited way to generate make include files to be used
with component specific, hand maintained makefiles.

The third priority is re-implementing the "execute sql" statement and
building a "services" provider. The Vulcan architecture has full
support for the services API in both user interface and the generic
provider class, but there isn't yet a services provider to field the
calls. The difficult problem is that the individual standalone
utilities that comprise the services module are a profound mess,
containing references to internal engine functions, engine threading,
engine thread data, and engine synchronization primitives, none of which
exist anymore. It's an open question of whether to the "services"
builds of the components or just start over. I don't know. Somebody
needs to do a careful investigation and make a recommendation.

The fourth priority is general improvements. This is include new
features and bug fixes from Firebird 2.0 and general upgrades of the
code, specifically including continuation of the engine mechanism
encapsulation process. The most important of these is the
transformation of the RSB mechanism into a proper C++ hierarchy.

Enterprises Warming Up to Firebird Open-Source Database

Evans Data Corp.'s Winter 2005 Database Development Survey looked at the database preferences of some 406 developers in mostly medium to large enterprises. Of those surveyed, 23 percent of developers picked Firebird for use in "edge" databases—in other words, those that are embedded in systems or in devices, such as a point-of-sale system in a retail outlet or a network device. Runners-up included Microsoft Corp.'s Access, at 21 percent, and Microsoft's SQL Server, at 13 percent.

RFID tagging will likely fuel interest in Firebird, said Joe McKendrick. McKendrick is an analyst for Evans, which is based in Santa Cruz, Calif.

http://www.eweek.com/article2/0,1759,1756876,00.asp

Vulcan Joins Free World!

The Vulcan source code joined the free world last week when the CVS tree
moved to the Firebird tree on SourceForge. Vulcan is now under the same
administrative policies as the rest of Firebird. All new and
contributed Vulcan code has been submitted under IDPL. The source tree
also includes the "buildgen" utility necessary to build Vulcan on
non-Windows platforms.

A technical description of Vulcan is available at
http://www.ibphoenix.com/downloads/VulcanOverview.pdf, including a
description of missing and incomplete components. I urge anyone
interested in Vulcan to start with this paper.

Vulcan is currently available as source with build procedures for
Windows (Visual Studio 7, also know as Visual Studio .NET 2003), 32 bit
Linux, 64 bit Linux, and 64 bit Solaris (Forte compiler w/ pthreads).
Ann and the Pauls are working on binary installations which should be
available soon.

Another document, VulcanRules.html in the vulcan directory, lists a set
of project management rules for the Vulcan project. The project is now
part of Firebird, so the rules are now advisory, not obligatory. They
are, in my opinion, still good rules.

There is not yet a Vulcan release schedule, nor do I expect to see one
before Firebird 2.0 ships. The source tree is open for development,
however, including propogation of features and bug fixes, as individual
developers feel appropriate, from Firebird 2.0. I personally think it
would be useful if the Vulcan and Firebird 2.0 ODSes were brought into
sync. I do ask that developers announce their intentions before
beginning a task rather than waiting until code is ready to submit.

Vulcan development was a long hard struggle, but now it's time for
Vulcan to take it's place in the Firebird project to sink or swim on its
merits. I think its good stuff, and I hope you will, too.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376

"Everything about Release 1.5"

A german Firebird 1.5 article entitled "Everything about Release 1.5" written by Thomas Steinmaurer is in the new edition of the German magazine "Der Entwickler". The magazine is available on February 3rd, 2005.

Global Temporary Tables

From Vlad Horsun:

Hi All !

During last two months i did some research and implementation of
global temporary tables. Here i want to show what i has done and listen
your opinions and critics.


Definition:

Global temporary table (GTT) is base relation with persistent metadata
definition, stored in database catalog (system tables), and temporary data.
GTT's can be two kinds - with data, persistent within connection or within
transaction only. Data from from different connection\transaction are isolated
one from others but metadata is common.


Syntax and semantics:

CREATE GLOBAL TEMPORARY TABLE
[ON COMMIT {PRESERVE | DELETE} ROWS]

Creates metadata for GTT and stored it in database catalog.
If optional ON COMMIT clause is omitted then PRESERVE ROWS is default.

CREATE GLOBAL TEMPORARY TABLE is usual DDL statement and
handled by the engine the same way as CREATE TABLE statement - when
issued all necessary entries made in system tables and when transaction
commited all other work are done by DFW. GTT differs from persistent tables
by two new flags in RDB$RELATIONS.RDB$FLAGS. ODS change not
required.

GTT's can have indexes, triggers, field and table constraints as permanent
tables. All constraints between any kind of permanent and temporary tables
follow the rule below:

a) references between permanent and temporary tables are forbidden
b) GTT with ON COMMIT PRESERVE ROWS can't reference on GTT
with ON COMMIT DELETE ROWS

There is a table for easyer understanding which references are allowed

Master: Permanent Preserve rows Delete rows
Child:
Permanent Allow
Preserve rows Allow
Delete rows Allow Allow

Domain constraints also can't reference on GTT.


Instantiation and cleanup:

GTT instance created when it first referenced, usually at statement
prepare time. Each instance has its own private set of pages on which
data and indexes are stored. When connection\transaction ends all
instance pages are released.


Storage:

Data stored on the same manner as persistent tables. At creation
time GTT has 2 pages allocated - primary pointer page (not necessary
actually) and index root page (all index definitions for GTT stored there).
Let call them "base" pages.

When GTT instance is created, engine allocate new primary pointer page
for it and index root page (this pages not tracked in RDB$PAGES) . "Base"
index root page are readed and all indexes from it created for given GTT
instance. All data\index operations with this GTT instance used this pages.

Storage can be inside database files or outside it. For external storage
purposes introduced concept of "page space" :

"Page space" is a set of pages enumerated from zero to 2^32-1 (SLONG)
on which engine can store all types of pages. Each page space reside in
it's own OS file or set of files. Engine has all necessary info about this files.

All database pages now reside within predefined "base" page space.
Pages of GTT's instances can reside within this "base" page space or within
additional page spaces created and dropped on the fly. Temporary page spaces
creation and deletion performed by the engine automatically. Files created
with "temporary" attribute set (on platforms which have such attribute).
"forced writes" set to "off" for temporary page spaces regardless of database
settings. All pages from all present page spaces are handled within common
page cache.


Blob "problem":

At blob creation time engine not know in which relation (permanent or
temporary) this blob will be attached when materialized. Therefore when blob
will be materialized may arise necessity to move it from initial ("base") page
space into page space of the appropriate relation. To avoid such waste of
time i propose extension of blob parameter block (used when blob created).
This extension allows to set initial page space in which blob pages will be
allocated before materialization. No public API change is necessary, only
few new constants.


Known limitations:

When user create new index already existing GTT's instances will not
know about it (and don't build it of course). Only new instances will read
new index definition from "base" index root page and build it.

This limitation seems not very important to me since this is usually
bad practice to change metadata on working database.


Work progress:

Almost all of said above is implemented in my private tree.

Current implementation allows to have follow kinds of storage for
temporary page spaces:

1. No temporary page spaces - all inside database
2. Page space per attachment
3. Page space per engine process (one common page space for SS or
separate page space per CS process)

Now it is hardcoded but can easy be moved into configuration file.
I have no strong opinion about how files for temporary page spaces must
be configured - where it must be created. Now i simple create each page
space in its own single file with predefined name:

sprintf(file_name, "fb_tmp_%x_%x", pid, hash);

where "pid" is process id and "hash" is hashed full name of primary database
file. Files are placed into GetTempPath(). As temporary solution and for testing
purposes its worked fine but for production use we must introduce some
rules for it.


Regards,
Vlad

FIXML

FIXML is a free utility which can export any table or Select sql
statement to xml.

Designed to work with: firebird 1 & 1.5x and Interbase 6 & 7

Visit http://www.tectsoft.net/Products/Firebird/FIXMLExport.aspx for
more info

Some Linux apps are small wonders

While it's easy to sing the praises of big applications like OpenOffice.org or the GIMP (and rightly so), the heavyweights of the open source world cast a long shadow over a host of much smaller, lesser-known apps that may do just what you need. One of the original philosophies behind Unix was that a program should do one thing and do it well. Here are a few programs that embody that philosophy.

Read more

Running Windows viruses with Wine

It just isn't fair that Windows users get all the viruses. I mean really, shouldn't Linux users be in on the fun as well? Well... thanks to the folks running the Wine project, Linux users can "catch the virus bug" too -- sort of.

Read the rest

Vulcan is now alive and well within the Firebird CVS tree on Sourceforge!

Vulcan is now alive and well within the Firebird CVS tree on Sourceforge. The Source Code can be downloaded and built from there using the module name of vulcan. For those of you who want to know more about Vulcan, we have prepared an overview document (.pdf), detailing the work that went into it, what still needs to be finished, how to build it and use it.

Embedded Firebird and MSDE 2000 Feature Comparison

Source: http://www.dotnetfirebird.org/blog/2005/01/embedded-firebird-and-msde-2000.html

This is a basic comparison of Firebird 1.5 and Microsoft MSDE 2000 that stresses the advantages of Firebird. The whole matter is not so simple, especially when you are trying to compare Embedded Firebird (that is not a standalone server) and not Firebird Server. I'm going to expand this comparison later (and to bring a Firebird/SQL Express 2005 comparison as well).

Feature	Embedded Firebird 1.5	Microsoft MSDE 2000
Deployment and Administration
Single database file		No
Embeddable	Details...	Limited*
XCOPY data deployment	Details...
Hot backup (24x7 availability is possible)
Can run on Windows 98
Scalability
Database file size limit	Unlimited***	2 GB
Multiple concurrent users		Limited**
Engine Features
Transactions
Views
Autoincrement fields
Stored procedures and triggers
BLOB fields
Unicode support
National character sets support (including sorting)
ADO.NET Provider
Licensing
Open-source license	Details...
License allows use in commercial applications	Details...

* Embedding. MSDE can be installed with the host application but it still is a separate server. You need to accept MSDE EULA before redistribution. Firebird can be installed as a server or can be used as as a part of the application (just a single DLL copied into the application directory that doesn't expose any TCP/IP or other interface to other applications).

** Multiple concurrent users. MSDE contains a workload governor which adds performance penalty when there are more than 5 concurrent connections working (NB working not just open).

*** Database file size limitation. Firebird is limited only by file system (e.g. 16+ TB on NTFS).

To summarize: Embedded Firebird is a clear win when you need a fully embedded database that users are not aware of. Comparing standalone Firebird server is a different story and we will come back to it later. The clear advantages of Embedded Firebird are:

• Licensing. You can't beat Firebird's open-source license that allows use in commercial applications without any viral effect (i.e. no need to open your proprietary code). Any kind of a "free redistribution" license is just too far from that.
• XCOPY Data Deployment. A Firebird database is a single file. Just copy it somewhere on disk and open it. Compress it and send it by e-mail. Use your own file extension and associate it with your application.
• XCOPY Runtime Deployment. Not only the data but the runtime (which is a single DLL and optional supporting files) can be just copied to your application's directory.
• Runtime size. Compare the MSDE 40+ MB download with the 2 MB Firebird runtime.
• No performance limitations. With Firebird you can have a database of any size and open multiple connections without any penalty.
• Real embedding. Users and administrators don't need to be aware that your application is using Embedded Firebird because it is only accessible from your application.

Related

• Firebird and Microsoft Jet Feature Comparison
• Firebird Can Be Easily Embedded
• Create a Database Programmatically

Migration from MySQL III. - AUTO_INCREMENT and LAST_INSERT_ID()

Source: http://www.dotnetfirebird.org/blog/2005/01/migration-from-mysql-iii-autoincrement.html


I mentioned already in Migration from MySQL I. that in Firebird you should use a generator instead of AUTO_INCREMENT:

CREATE GENERATOR GEN_MYTABLE_ID;

SET TERM ^ ;
CREATE PROCEDURE SP_MYTABLEINSERT (
MYTEXT VARCHAR(20))
AS
DECLARE
VARIABLE ID INTEGER;
BEGIN
ID = GEN_ID(GEN_MYTABLE_ID,1);
INSERT INTO MYTABLE (ID, MYTEXT) VALUES (:ID, :MYTEXT);
END^
SET TERM ; ^

In that example we used a stored procedure SP_MYTABLEINSERT to insert the data. If you need to get the number that was returned by the generator you can modify this stored procedure to return the generator value:

SET TERM ^ ;
CREATE PROCEDURE SP_MYTABLEINSERT (
MYTEXT VARCHAR(20))
RETURNS (
ID INTEGER)
AS
BEGIN
ID = GEN_ID(GEN_MYTABLE_ID,1);
INSERT INTO MYTABLE (ID, MYTEXT) VALUES (:ID, :MYTEXT);
SUSPEND;
END^
SET TERM ; ^

We increase the generator value by one and store the result in ID variable. After modifying the stored procedure header we now return the inserted id.

Migration from MySQL II.

Source: http://www.dotnetfirebird.org/blog/2005/01/migration-from-mysql-ii.html

If you are missing a tool like phpMyAdmin when coming from MySQL, you should try ibWebAdmin.

• Screenshots
• Download
• Documentation

Migration from MySQL I.

Source: http://www.dotnetfirebird.org/blog/2005/01/migration-from-mysql-i.html

Why you should do that:

• stored procedures support
• views support
• transactions (these are also supported in InnoDB tables in MySQL)
• friendly open source license that allows commercial use and embedding for free
• embeddable (with a small runtime)
• hot backup

How to:

1) Autoincrement fields

There are no autoincrement fields in Firebird. You need to use a generator. It is a server variable that stores the last number used. You need to call it when inserting a new row:

• in an inserting stored procedure
• in a trigger

Given that we have a table

CREATE TABLE mytable (

 id INTEGER,

 mytext VARCHAR(20)

);

the generator would look like this:

CREATE GENERATOR GEN_MYTABLE_ID;

the trigger would look like this:

CREATE TRIGGER MYTABLE_BI FOR MYTABLE

ACTIVE BEFORE INSERT POSITION 0

AS

BEGIN

 IF (NEW.ID IS NULL) THEN

 NEW.ID = GEN_ID(GEN_MYTABLE_ID,1);

END

and the inserting stored procedure like this:

SET TERM ^ ;



CREATE PROCEDURE SP_MYTABLEINSERT (

 MYTEXT VARCHAR(20))

AS

DECLARE VARIABLE ID INTEGER;

BEGIN

 ID = GEN_ID(GEN_MYTABLE_ID,1);

 INSERT INTO MYTABLE (ID, MYTEXT)  VALUES (:ID, :MYTEXT);

END^



SET TERM ; ^

2) NOW()

MySQL:

SELECT * FROM mytable WHERE mydate = NOW();

Firebird:

SELECT * FROM mytable WHERE mydate = CURRENT_TIMESTAMP;

There are three special variables for current date and time:

• CURRENT_TIMESTAMP (date and time, TIMESTAMP type)
• CURRENT_DATE (date, DATE type)
• CURRENT_TIME (time, TIME type)

3) LIMIT x, y (return first y rows starting at offset x)

In Firebird it looks like this :

SELECT FIRST y SKIP x * FROM mytable;

LIMIT x (take first 10 rows) looks like this:

SELECT FIRST x * FROM mytable;

See also http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;IBPHOENIX.FAQS;NAME=.

Components4Developers are happy to present kbmMW v. 2.50.00.

kbmMW v. 2.50.00 is currently running in beta test.

With this release, new SKU's are being introduced, OpenSource, Standard, Pro and Enterprise.
Existing kbmMW v2 license holders will automatically be upgraded to a special SKU referenced to as kbmMW ProPlus.

Some of the major new features to mention:

- FULL safe .Net serverside and client side support for D2005.Net.
- Safe .Net client side support for Compact Framework
- Java client side support in addition to the existing Java serverside support.
- D2005/Win32 support
- Additional messaging capabilities including support for loadbalancing and persistant message stores.
- Loadbalancer teaching and learning capabilities.
- Additional database adapters.
- Highly detailed Windows Performance Monitoring support for complete application server monitoring.
- Even higher performance for certain areas.
- and much more!

Please checkout feature matrix and price information on site at www.components4developers.com

Fulltext Search in Firebird

Source: http://www.dotnetfirebird.org/blog/2005/01/fulltext-search-in-firebird.html

Firebird doesn't support fulltext search. You need to rely on third party tools. That seems odd, but it doesn't have to be so bad as it looks at first.

I am using DotLucene. It is an open source .NET library (ported from Java) that can index any data (structured or unstructed) that you are able to convert to raw text.

On a server, it is no problem to store the index in a separate directory (you can also load it to RAM to make your searches super fast - if you have enough RAM, of course). In a desktop application, it might be useful to store the index in a Firebird database.

For example: MySQL fulltext search has these drawbacks (compared to DotLucene):

• You can use it only in MyISAM tables (i.e. no transactions)
• You can't browse the index (see Luke)
• You need to store transformed text in the DB (i.e. HTML without tags)
• It doesn't support highlighting of the query words in the result
• You will hardly modify the sources to do custom changes
• The license doesn't allow to use it in commercial application for free
• It is reported to be slow on large data sets

IBFirstAID 1.5 and IBAnalyst 1.7 are released

What's new in IBFirstAID 1.5

• Support for multi-volume databases. Now IBFirstAID 1.5 is able to diagnose and repair databases which contain several volumes.
• Detecting and fixing BLOB errors. IBFirstAID 1.5 walks through each BLOB in every table and checks its integrity, alerts errors and fix links to corrupted BLOBs.
• Page Inventory Pages (PIP) repairing. Missed page inventory pages will be automatically recreated if needed. It increases capability to repair databases with large amount of lost data.
• Improved repairing of pointer pages errors. IBFirstAID recreates and chains again missed pointer pages.
• Enhanced algorithm of data pages checking and repairing.
• Fixed bug with large databases checking
• Fixed bug with index checking for InterBase 7.x databases
• Improved user interface
• New license types: Site License allows to use IBFirstAID on all computers in your company and Vendor License allows you to use IBFirstAID to fix your customers databases

What is new in IBAnalyst 1.7

• Improved transaction state view (Summary page) with rewritten hints and recommendations.
• Graphical transactions relation representation (Absolute and relative view)
• Additional computed numbers that helps to understand database load (average transactions per day, active transactions %, frequency of automatic sweep start and so on).
• Massive updates/deletes detection
• Tables fragmented by blobs detection
• Useless indices detection
• InterBase 7.5 index null keys report
• Ability to copy data to clipboard (right mouse click)
• Examples of statistics with explanations
• New Options (Transactions, Tables, Indices, Interfase)
• Additional documents, explaining getting statistics and Summary page owerview.
• Improved analytic algorythms and hints

Download free installation of IBFirstAID 1.5 Diagnostician

Download free installation package of IBAnalyst 1.7 Evaluation