I used to do the backup of SYB 10 with DBBAckup, but after stopping the DB ( script netstop db, dbbackup, netstart db )

What did the connection string look like on the dbbackup command line? Did it use a DSN with autostart specified?

The reason I ask is that the dbbackup.exe only does warm backups; i.e., it only connects to a running database, so in order for it to work on a stopped database it would have to autostart it... then, if the DSN also specified autostop, the database engine would stop when dbbackup was finished thus allowing the netstart to work.

If that's not the explanation, then I certainly want to hear about it! ( I can feel the ground shifting 'neath my feet :)

The OS file system datetime for the *.db and *.log files is not changed every time data is written to the files. I can't remember what exactly the rules are, but AFAIK if the files change in size then the datetime is updated. Variations in the file datetimes are very common and of no concern... do not rely on those datetimes for anything.

How can I be sure that this backup is correct, and includes the latest transacations done?

Dmitri answered "trust it" in the newsgroup... and initially I thought that was too glib but I'm having a hard time coming up with a better answer, such as a test you could perform after every backup.

( in practice, glib or not, Dmitri's answer works for me :)

Anyway, here's one possibility, probably best suited for a one-time test: Create a test table and insert a row with COMMIT just before doing the backup. After the backup is complete, start the backup database using the backup log, in the backup folder; specify a different -n server name on the dbeng10 command line to avoid conflicts. The database start process will go through normal "recovery" to apply the log to the database. Then, do a query to make sure the test row is there.

You could do a test with two inserted rows, one committed and the second one not. After the backup database is started, only the first row should be there because the second row was not committed... that is expected behavior: the original connection that did the uncommitted insert does not exist on the backup database so the intent (commit or rollback) is unknown, therefore rollback must be assumed.