Ibsurgeon First Aid 3.5 150
Keena Wiegert
It uses its layer for low-level database access without using the InterBase or Firebird engine, so it can perform real "surgical" operations and repair your database when all other standard mechanisms (gfix and gbak) cannot.
Usually, database corruption means that some links between internal structures of Firebird (or InterBase) database are broken. When the database engine sees a broken reference to the missed record or database page, it stops working with a message like this:
Such error messages are reported by gbak tool, by gfix (it writes them into firebird.log), and by end-users applications (you can see the full list of "software consistency check" errors here).
The first part of this error is a common prefix for bugcheck (i.e., serious error), and in the parentheses, there are details of the error.
Usually, such error prevents normal work with the database, and the recovery procedure should be executed. If it was not possible to fix a corrupted Firebird (or InterBase) database with standard means (gfix.exe and gbak.exe), it is time for IBSurgeon FirstAID.
IBSurgeon FirstAID can perform 2 kinds of recovery operations: direct recovery and data extraction. The direct recovery is intended to fix the original corrupted database in place. This is a very fast and efficient method: after fixing the broken links database usually becomes readable, and it is possible to perform backup and restore. There are detailed instructions in FirstAID Recovery Guide on how to use the direct fix in FirstAID and then perform final steps with gfix and gbak tools.
Important! If you cannot see data with FirstAID in your corrupted database, please contact our support: [email protected]. Please send the diagnostic log and relevant details (full error text, screenshots, etc) to our support, and get recovery estimation for free.
You will receive an exact free answer on whether your database is recoverable or not, is it recoverable by FirstAID directly, or some manual work is needed. We will also try to estimate how much of your data can be recovered if there is a serious problem that will not allow 100% recovery.
If you are ISV (Independent Software Vendor, i.e., your company produces business software that uses Firebird or InterBase) or you have many databases, 50 databases license should be a perfect choice.
HQbird Enterprise is our flagship product, it includes the following features: high availability and replication, recovery toolset for 100 databases, GUI for database development, backups' automation, transaction and queries monitoring, database structure analysis, optimized configurations and more.
Gfix scans the database, checks data structures and records for corruption, and fixes them.
Please note: It is necessary to run gfix after FirstAID Direct Fix, and it can be skipped in case of extraction since the database for export is not corrupted.
After the successful gbak, the restore must be done to create a fresh database from the backup. The command is the following:
gbak -c -user SYSDBA -pass your_pass Path_to_backup Path_to_database
When setting up the connection, the path to the database is always given
from the perspective of the server. For easier setup, an alias is
created for the client - a name which a database file refers to. This is
done in the aliases.conf file. The syntax is:
Depending on some of the features of the connection type, the security
requirements, optimisation, or the presence of another instance of
Firebird, additional configuration may be necessary. The configuration
file is firebird.conf. You can edit the file with a text editor.
Under restrictive firewalls or when the port is given as an exception,
rather than the application in the OS Firewall, you must set up a port
for the message exchange between the server and the client. By default,
a random port is used.
In Firebird, limits can be set regarding the database location, i.e.
where the database can be located. The client can choose where to
restore a database, which is considered a potential threat - if the
server process has higher access rights, the database can be created in
the wrong place. The limitations are created by adjusting the
DatabaseAccess parameter. The options are Full, Restrict,
and None. Full is used by default.
Depending on the client requirements, it is recommended that the
Restrict or None option is used. This depends on whether the
client works mainly with aliases or with determining a path to the
database.
The databases can also use external files. The setup options are the
same as those for database access. Currently, AuditDesktop databases do
not use external files and it is desirable in this case that the setting
to be None (it is such by default).
In cases of large amounts of data, number of connections, etc., you can
change some parameters concerning the usage of system resources.
Depending on the available resources, you can change some values to
increase productivity. Sample configuration files with optimised cache
parameters can be found at the following address:
-firebird-configuration/.
When using SuperServer, the first processor core is used by default. The
value is set as 1 - first core, 2 - second one, 3 - first and second
ones, 5 - first and third ones, and so forth. Setting more cores in a
SuperServer is effective only if two or more databases are used.
Regardless of the creation method, you have to ensure that the Firebird
process has appropriate access rights to use/create database files. In
other words, the user that starts the service must have sufficient
access rights to read, modify, and possibly create database files.
When working with AuditDesktop, it is not necessary for clients to see
the database file on the network, i.e. it does not have to be shared. To
ensure a higher security level, sharing the FDB file on the network is
not desirable.
If you want all users to share the same configuration, when you edit the
database connection setup, select the Application
folder option in the Database connection configuration. After the
settings are saved, the following file will be created in the
Application folder: auditdesktop.xml. In this case, all users
who start the program from the shared location, will see this setting.
If nothing else is needed, share the folder as Read-only. Only
people responsible for configuration and updating will have editing
permissions on the folder (if that is not performed only by the server).
Yes, that's something I noticed specifically with Firebird. It seems other databases don't have that much difference between LEFT and INNER joins. Aurelius for now uses LEFT JOIN for the association joins.
Aurelius for now use LEFT JOIN because the queries can become very complex, with several associations involved, at multiple levels, and also inheritance. Using INNER JOIN plain and simple might break SQL. A more complex algorithm needs to be implemented to support both LEFT and INNER joins when needed. We have it almost done but it's not concluded yet.
One of our customers has been having performance too issues and I was looking at this article -aid.com/en/articles/45-ways-to-speed-up-firebird-database/ and wondered if the point made here may help, however I suspect that would be hard to do in Aurelius
Does any one here could provide a use case that demonstrates performance issues of Aurelius with Firebird in those specific cases? We are working in a refactor that might be able to solve those issues. We appreciate if you could provide a test case so we can measure and make sure performance was effectively improved.
Of course in this case the solution is simply to use an INNER JOIN since there is no ITEMS without an INVOICE (no detail without master). OR use a RIGHT JOIN to have the same results as the first query (INVOICES without ITEMS).
Some queries using JOINS (CreateAlias) may be affected by this problem. One possible improvement would be to use INNER joins when the [Association] attribute has the TAssociationProp.Required option set (and of course the Entity --where the association is defined-- is left side).
HQBird (a comercial and improved Firebird from IBSurgeon) just released its v2022 update 1 (for Firebird 3 and 4) with an optmizer improvement that implicitly converts LEFT joins into INNER joins when there is a (where) condition on the right side (table). That's probably what most databases do, and currently lacks in Firebird.
Open (make a copy) Aurelius.Sql.Firebird and override method GenerateJoin in TFirebirdSQLGenerator class. This is not a virtual method in the base class so you will have to open Aurelius.Sql.AnsiSQLGenerator and make it virtual in TAnsiSQLGenerator class.
b1e95dc632