Here's a short step-by-step walkthrough:
- disconnect users and disable incoming connections to the database
- make a copy of database file (or two copies) and work on that
- use GFIX with -v option to validate the database file
- use GFIX with -v and -f to do full validation
If problem is not too serious, you can try to backup the broken db and restore under a new name:
- use GFIX -mend to prepare corrupt database for backup
- use GBAK -b -g to backup the database. -g disables garbage collection
- use GBAK -c to restore backup to a new database.
If you succeed, you have fixed the problem and have a functional database. If not, you can try to create an empty database with the same structure and pump the data to it .
One of the reasons why backup or restore can fail is if some broken database triggers exist, and prevent connection to the database. For example, a database trigger might use some table which has a broken index, etc. To work around this, connect to database with isql tool using -nodbtriggers option and then disable those triggers. You can enable them later when you fix other problems and get a working database again.
Another reason restore might fail is when you have broken data, so some of validity constraints (check constraints, etc.) cannot be satisfied. In this case, you can try to restore your database using -N[O_VALIDITY] command switch to gbak.
If you're interested in a more detailed information of the process of fixing the database, as well as explanation of some types of corruption, take a look at the following page:
http://www.ibphoenix.com/resources/documents/search/doc_5
If all fails, you can try IBSurgeon tool, which is able to fix most problems and extract data. Also, IBSurgeon's website has a detailed
explanation of causes of database corruption and ways to fix it:
http://ib-aid.com/option,com_content/task,view/id,58/Itemid,62/
check this guide http://www.firebirdfaq.org/faq324/
There are a number of things you need to know when using the monitoring tables:
- The monitoring tables (like
MON$STATEMENTS
) provides you a list of the active or prepared statements at the time a query was run.
- The query result stays stable until the transaction is committed! This means that repeatedly executing the query without committing will not yield new information.
- Only
SYSDBA
, the databaseowner or a user with role RDB$ADMIN
can see all information, other users can only see information about their own connections.
- Your Firebird installation contains basic documentation on the tables in
doc/README.monitoring_tables.txt
Now as to your screenshot: all statements are from the same connection (your own): MON$ATTACHMENT_ID = 1521
. Only one statement is currently active (MON$STATE = 1
) and participating in transaction MON$TRANSACTION_ID = 90964
and was started at 2012-12-06 10:08 (MON$TIMESTAMP
), the rest is inactive (MON$STATE = 0
) and therefor has no transaction-id and timestamp. The first statement is also the only one that currently has an actual query (MON$SQL_TEXT
), which is the query that actual produced the result in the screenshot. In Firebird statements are allocated separately from the actual query to be executed using that statement.
That is not much, but if you had joined to MON$RECORD_STATS
, MON$IO_STATS
or MON$MEMORY_USAGE
based on MON$STAT_ID
you would have received statistics on the query (ie the number of reads, records update, number of pages read or written, memory use). The monitoring tables show information at a specific moment in time, and if a query has already finished when you execute it, you don't get any info (I am not 100% sure, but it might remain available until the next execute of a statement, or until the statement is unprepared or closed).
If instead you need a stream of information and statistics, than you might get more out of the Firebird Trace API. I haven't used it much myself yet, but the article Audit and Trace Services in Firebird 2.5 by Thomas Steinmauer provides a good introduction to it.
In your question you say you expected 'more content', but didn't actually specify what content you need or expected; I hope this provides sufficient info.
Best Answer
While I'm pretty sure you should redesign your database at first (and probably read something on SQL basics), you can get what you want with triggers :)
This one inserts row into
daily collection
with appropriate balance:And this one updates balance in
masterlist
after updates ofdaily collection
(assuming date is the primary key):