Time stamp Error after moving data in 2.01B

I am having an issue with datatbase files not being compatible due to the timestamp is not the same on all databases. Moved all data to new drive, opened database0 and have been locked out ever since…any suggestions?

Here is what actually happened: 2 Drives, D: and H: 7 FDB files existed on D:\Navisvr and they were copied to h:\Navisvr due to space issues on the D: drive nthat were leading to constant crashes. The first file in the the series was opened on H: but attempted to access the other 6 files on D: and apparently did so successfully. ONce it was determined that the better way to make the file system move was to do a Backup/Restore to a new set of files the files on H: were removed to start over with the data on D:. It turns out that a timestamp was set across 6 of the seven databases on D: that made them different than the first FDB file in the same directory. Navision wil no longer allow us to view the databases and displays the following error message: “The Database files are not compatible. The Time stamps are not the same. One or more of the files has been used later than the rest of the files. This can be because a backup has been only partially restored. Try to find database files that are all stamped with the same date and time.” Sounds easy, but we no longer have the file with the same stamp (even tried low level undeletes, but with no luck.) It also turns out that this weeks differential backups were failing and the last good backup we have is one week old. (We are prepared to do ANYTHING to prevent going back a week) HELP!!!

Just an FYI to anyone who maybe thought this was a tough scenario. IT IS! We have had to take all of our data (server and the attached storage array)to Navision’s US Corporate HQ. THe developer handling our situation thinks he can make a recovery. I will keep you posted. We were lucky no updates were posted across files as the server was never made available to end users during process. Please, wish us luck!

The bad news is that you have also deleted the files from H: If you didn’t you should also be ables of re-opening the database by just copying all the files from H: to D: but the first one. When you’re using a database with multiple files the database is keeping the path to the files also, so for moving it you’ve to create the same path structure and use the same drive on the new destination. If you’re not able of doing that, you need to create a backup and restore it onto a new empty database.

You don’t have to recreate the path structure. Just open the database with file1.fdb+file2.fdb+file3.fdb in the “Database Open”-dialog or from the command prompt if You have moved a database with multiple files. And Alfonso. I think You meant that Steve should have copied just the first file back to D, since this one had the same timestamp as the other six on D: /Lars

Well… in fact i was thinking on the opposite… as the first file from H: was having a modified timestamp but was opening the files on D: if the other files on H: (all excepting the first one) were a copy of the ones in D: copying them back to D: will also solve the problem about the time-stamp as the first file on D: should be unmodified, so he’ll have back the database as it was before opening it on H: It’s almost the same you’re suggesting but instead of using the modified database that was first open in H: it’s using the original one… :slight_smile: You’re right… i forgot about the file1.fdb+file2.fdb… etc way… :slight_smile: the problem is that whenever you’re setting up for opening the database you’re having to remember to add file1.fdb+file2.fdb… etc… and it’s easier if just restoring a backup into an empty database :slight_smile: