InterBase Myth #1

When performing a “restore” outdated, versions are deleted (and, therefore, are stored in backup) or gbak -g creates a backup file without versions, and by default versions are included in the file.

Nothing of the kind! No records versions are stored in a backup because it is unnecessary. Generally, the backup process is an ordinary snapshot transaction (repeatable read), and it reads only those records versions, which were relevant at the beginning of the transaction. The “no_garbage_collect” flag controls collecting garbage versions in the database itself. This flag can also be used during ordinary connections accessing the AP (i.e. in applications, when, say, one needs to accelerate sampling in some cases).

InterBase Myth #2

Record versions are created during reading

Versions are created only when records are changed or deleted (UPDATE or DELETE). On the contrary, if unnecessary versions of the same record are detected, they are marked as trash (i.e., they would be deleted). Read as much as you want, this will not result in creation of new versions. Vice versa, updating of a record creates a new version of the record in any case, disregarding the fact that someone else reads this record. A myth sometimes becomes true: versions of the records may be created during reading, but only in Firebird 1.5 (and higher) in queries select … for update with lock. More detailed information will be published in the next issue of full title.

InterBase Myth #3

Database files (gdb) must be shared with users

Never do that! InterBase – is not a file server, and works with databases independently. A client only informs the server, which database he/she wants to work with, and what queries are to be executed.

InterBase Myth #4

If I see the word NATURAL in the query, it is a bad one!

Nothing terrible. Some data retrieval (depending on query) is better by natural table scan, than by an index scan. It’s better to check, how long time ago you refreshed statistics for indices in your database. See documentation about SET STATISTICS INDEX <index_name> statement.

InterBase Myth #5

InterBase is designed for Windows, and therefore it is incompatible with Unix (Linux, Solaris, etc).

This is not true!First version of InterBase was created for Unix, and, before the Windows-version was released, there were 15 “ports” for different Unix versions (AIX, IRIX, SCO, HP-UX…). Actually, the Windows version was released 7-8 years after the first version of InterBase

InterBase Myth #6

Compiled procedures store query plans.

Not a bit (unless the query plan is explicit)! This myth is based on the fact that the procedure after first call (that is the moment when query plans, written in the procedure, are computed) remains in the metadata cache until all clients, who called this procedure, disconnect. In this case, actually, while the procedure is in memory, query plans do not change, even if statistics of the indexes used by the plans change. Read about this in InterBase documentation - DataDef.pdf, Chapter 9, section “Altering and dropping procedures in use”.