Need the repair utility
richard
Posts: 19
I am unable to connect to one of my servers through the GUI. I am getting the following error
Failed to open local data store: The database file may be corrupted. Run the repair utility to check the database file. [Database name=C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Data\"INSTANCENAME"\data.sdf]
I am also getting backup errors for one of my databases when doing log backps, which I think is related to the above
Failed to open local data store: The database file may be corrupted. Run the repair utility to check the database file. [Database name=C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Data\"INSTANCENAME"\data.sdf]
I am also getting backup errors for one of my databases when doing log backps, which I think is related to the above
Comments
1. stop the sqlbackup service
2. delete\rename the data.sdf file
3. restart the sqlbackup service
The repair utility is SQL Server Management Studio. You need SSMS installed on the same physical servers that holds the Data.sdf file. Then connect to it specifying SQL Server Compact Edition as the "Server Type". Browse to the data.sdf file, and SSMS will recognize that it is corrupt and give you the option to repair it.
Of course you can also delete or rename the file, as you did, and a new empty file will be created.
Roughly how often does this happen? Also, does this usually happen on, or after certain SQL Backup operations (such as full/diff/log backups, log copying, or restores).
Thanks,
Development
Red-Gate Software
I would estimate that it happens on a few random instances every week. Generally for me the corruption has occurred when a Cluster failover (Gennerally Planned) happens.
Also note that the frequency of this error increased with the upgrade to 6.x.
In my case the cluster is PolyServe not MSCS and I have since recently implemented scripts to try to keep the SQLBackupAgent_InstanceName service active only on the active PolyServe node. Time will tell if the scripts implemented have fixed the problem for me.
Nevertheless, I would still request that a future release not use SQL Server Compact Edition to store backup history. We already have a SQL Server being backed up. So the existing SQL Server could also be leveraged to store the Red Gate SQL Backup historical data and it wouldn't be so fragile.
also agree that the history collection via sql compact edition is not great
in the end I did the following to fix the error permanently (touch wood)
- de-licensed sqlbackup on that server
- completely uninstalled sql backup
- removed the red-gate dirs in prog files and all users
- reinstalled