- December 10, 2010 at 2:54 pm #31169
I’m trying to backup a database that was created with an older CO version (1053 or 1055 – whatever was current in June) then just upgraded to 1058 before backup. Using CO starter edition v1058.
I’m getting an error as in the screenshot – this is on a single user PC with DB in local folder, and there is only one copy of CO running. VSS is enabled for Mozy and Shadowprotect Desktop backups.
Tried doing a Check and Repair – this found no errors and didn’t fix the problem.
There’s no important data in the DB but it does have the customizations I’ve done to date – is there some way to export those to a CSV file or similar?December 13, 2010 at 9:35 am #32615
Hi – thanks for your post. You can download the 1053 or 1055 updates from the following links :-
Installing these older update files will ‘roll back’ your ClinicOffice installation to that version. However, this shouldn’t be necessary and you should be able to restore any database on any version.
If you have no success, please send our support team an email (firstname.lastname@example.org) with the database backup attached (as long as it’s not too big) along with a full description of the problem and we take a look for you.December 13, 2010 at 10:33 pm #32616
Hi – for some reason the screenshot upload didn’t work… trying again with this post, see attachment (scroll down a bit for the error):
[attachment=0:y8w9k9s1]Error on backup.png[/attachment:y8w9k9s1]
The problem is with creating a backup, not with a restore – no backup file is created and the error 700 shown in screenshot is displayed.
There is only one CO process on this system, and it’s a single user setup.December 14, 2010 at 12:00 pm #32617
Please can you send our support team an email (email@example.com) with the database backup attached (as long as it’s not too big) along with a full description of the problem and we take a look for you.
If the backup is larger than 2 MB then please can you upload it following these instructions :-
Many thanks.December 14, 2010 at 3:13 pm #32618
Uploaded the DB to your FTP site and emailed support – thanks.December 14, 2010 at 9:38 pm #32619
Thanks for sending your database. We have restored it on a test machine, we have logged on, tested the core features, logged off, taken a backup, restored the new backup and re-tested the restored database and we cannot find any problem at all.
If this problem persists, then most likely it is an issue with the installation of ClinicOffice on your computer. Please completely uninstall ClinicOffice then download the full installation again from here :-
pioneersoftware.co.uk/files/cov4/cov4_setup.exeDecember 18, 2010 at 9:54 am #32620
Thanks for the response. I’ve tried some more things, with no effect on this except as mentioned:
– uninstalled CO then re-installed v1058
– rebooted PC
– exited CO then ran again, and tried the backup before logging onto the main SLT DB
– did backup of the sample database – first backup went fine, but on re-running CO and trying again I got the same error. So I’m getting this error on both DBs, but it’s intermittent on the sample DB and fully repeatable on the main SLT DB (which is the one I’ve been using).
As you mentioned, it does seem to be something to do with this installation, not the DBs.
Are there any issues with CO and VSS (volume shadow copy) based backups? I’m using both Mozy and ShadowProtect Desktop. Would it help if I excluded the COv4 data directories from Mozy temporarily? I can’t exclude from ShadowProtect as it’s an image based backup.
Also, what happens if CO is run in the morning and is still open when Mozy does a VSS based backup at night – do the files get backed up in the state as of first run, due to VSS?December 19, 2010 at 6:00 am #32621
>> Are there any issues with CO and VSS (volume shadow copy) based backups?
No, there are no known issues.
>> Would it help if I excluded the COv4 data directories from Mozy temporarily?
Yes it might be an idea to try that.
>> Also, what happens if CO is run in the morning and is still open when Mozy does a VSS based
>> backup at night
That’s really a question for your backup company and how it handles files that are in use.
The error in the ClinicOffice screenshot that you posted indicates that the database files are in use and locked at the time when ClinicOffice is trying to work on them. We’d recommend disabling any applications (continuous backups/anti-virus etc.) which may be locking the files to see if you can discern which program is causing the problem.January 9, 2011 at 2:53 pm #32622
This seems to have fixed itself – I deleted some test data, and also restored from a separate file-level backup to revert some customizations, and backups now work fine on this database… same installation of ClinicOffice. Can’t quite work out how this has fixed things but it has, for now at least.
It’s also rather odd that the specific error message suggests a syntax error in a statement – see the screenshot in my 2nd post.
You must be logged in to reply to this topic.