When are database entries actually posted / updated ? 1

[StevenK]

Label me confused.
I've been working against Interbase databases for some time now (from Delphi applications).
Someone has recently suggested to me that transactions are not actually been processed against the database when I'm expecting them to have taken effect.
From within the scope of my applications / SQL statements I can see no evidence that there is any validity in their comment.
However one thing that has puzzled me is the date-time stamp (Modified) against the '.gdb' object when viewed through Windows Explorer and the likes.
The date/time stamp show the time when I logged onto the database (be it through SQL Explorer or through the TDatabase component in my Delphi application).
I can be in a position when I make various posts within my application - I'm labouring under the impression that the transactions have been posted / updated as the data as seen through the forms reflects the additions / changes made.
However my date-time stamp remains constant until I close my application / shut down SQL Explorer.

I'm guessing I'm missing something fundamental here - can someone enlighten me so I can better understand this.
Is it something that I should be concerned about ?

Thanks for any input / feedback in advance.
Steve

 

[svanels]

I think that only when the database receives thecommit command it validates the changes permanently. Steven van Els
SAvanEls@cq-link.sr

 

[StevenK]

We're performing the 'Commit' command against TDatabase transactions.
I'm labouring under the impression that these transactions have been posted / committed as I can see the results of the workload through the application itself and similarly when I run SQL statements through something like SQL Explorer. So I'm going under the assumption that the data updates have been made.
However my date-time stamp against the '.gdb' file doesn't change until I close my TDatabase component when I close the application as a whole.
What am I missing here ?
Thanks so far.
Steve

 

[MartijnTonies]

As you don't have any control over the file, you have to wait until the server process closes/modifies the file. Is "forced writes" ON for this database? That seems to help.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird

http://www.upscene.com

 

[StevenK]

Where would I find the 'forced writes' setting ?
Is it against Interbase as a whole, the database file or within the TDatabase component in my source files ?
Thanks in advance.
Steve

 

[MartijnTonies]

It's a per-database setting. You can set it with "gfix" (command line tool), or IBConsole (GUI tool) or the tool I wrote - Database Workbench (

http://www.upscene.com

) ...

Check the documentation on how to set it.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird

http://www.upscene.com

 

[StevenK]

Using IBConsole it appears that the database file in question has 'Forced writes' set to 'Enabled'.
I'm assuming that this has been set by default (as it's not something I'm familiar with so would not have been something I would have changed myself).
However, I still face the issue where the date/time stamp against my database file is not updated when viewing through external means (Windows Explorer and the like) - albeit that I am seeing that the data is changing when viewing it through different means (the updates/inserts/deletes are taking effect within the table data).

Can anyone suggest why the file's date/time stamp would not be changed when data is being updated within the file itself ?

Thanks for everyone's suggestions so far.

Steve

 

[MartijnTonies]

How about (simple) file-caching. The OS will cache the file as well - Windows especially. Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird

http://www.upscene.com

 

[StevenK]

How do I allow for the file-caching of the OS ?
We recently visited our client site and took copies of the Interbase database along with Paradox tables (the two feed back and forth within the scope of the application).
We came to the conclusion that the two (Interbase / Paradox) were "out of sync" and have since fingered the Interbase as being the issue.
What do we need to review in order to get around this ?
Steve

 

[MartijnTonies]

You shouldn't copy the file - it's much better to create a backup using "gbak" or IBConsole.

When you allow yourself to copy the file, it might be in use, even when no-one is connected. This can 'cause terrible database corruptions.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird

http://www.upscene.com

 

[StevenK]

How can we make use of the 'gbak' application in order to run a nightly backup of the Interbase database file ?
Can this be done through creating a program / service to run on a timer or something like that ?
Thanks in advance
Steve

 

[MartijnTonies]

Hi,

Use the Windows scheduler to start a batch file with a "gbak" command in it. See the InterBase documentation on how to use gbak - that will help.

You can use/transfer/backup to tape etc the output of gbak and do whatever you like with it.

The usual way of working with IB backups and 3rd party backup software (and any database engine, for that matter), is to use the database engine specific software to create a backup of the database and then use the 3rd party software to backup the database backup as part of your normal backup process.
Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird

http://www.upscene.com

 

[StevenK]

Martijn,

Many thanks for all your feedback on this matter over the last couple of days. We'll look at putting these suggestions into practise over the coming couple of weeks.
Thanks again.
Steve