As you know, Synchronise = OFF speeds up the database operation considerably. I was looking at the previous post about this subject and am now wondering what the actual risk is? Is it that data may corrupt ONLY during the time files are synchronized or playlists are generated? I like this setting and am wondering whether there are reasons not to use it.
The risk is only ‘minimal’ until it happens to you. Then you may find your entire DB is screwed.
I would STRONGLY recommend that you take a simple backup copy of your DB file to AT LEAST ONE different physical drive AT LEAST every 24 hours: perhaps less frequently if you don’t modify the database much, but I’d say NEVER less frequently than once a week. Backing up to two or more different physical drives (apart from the ‘live’ copy used by mAirList applications) reduces the possibility of irrecoverable data loss by a further 50%.
If you know your Command (.bat or .cmd) files, you can create the required COPY command(s) as one of those, then schedule it using Windows Task Scheduler to run as required, so that you never ‘forget’ to do it.
Once again, you have offered valuable information. Thank you for the dose of reality ;).
I had thought the database was safe because I don’t modify the database much and the Synchronize=off would create problems only during write-operations. I do manually copy to a different drive–but not as frequently as I should :(.
Do you see a concern using the Sychronize=off, provided frequent back-ups are made?
I’ll create scheduled back-ups using NTBackup.exe, located within XP.
No. See my previous post above. You are correct in saying that the only risk from sync=off is while something is being written to the database.
Hmm … seems like overkill, unless you are backing up lots of OTHER information as well? A mAirListDB database is a single .DB file (unless you are using the network PostgreSQL version). A simple COPY command in a batch file is faster and simpler than ntbackup, and it’s easy to schedule the resulting batch file using Task Scheduler.