Error during Database restore - access file

Denis_Petrov

We have a Native Navision database (4.01) with 175 companies.
I have a complete backup, only 7 companies need to be updated (with most recent transactions done on a backup server).
So I took the original database and deleted those 7 companies. Tried to restore 4 so far, 3 companies worked just fine. Forth company ("X"), being the largest, gave this error message (while Creating Keys, the last step of the back up!):

The operating system cannot gain access to the file .
Please check that the file type and attributes are correct.

Why? :?: Three companies worked fine, so restore works for companies but not all? Any ideas?
](*,)

DenSter

Assuming that you're on SQL Server, I would bet that the drive that your transaction log is on has filled up to its maximum limits. Did the restore roll back completely or is it just sitting there now?

Savatage

DenSter wrote:

Assuming that you're on SQL Server

Denis Petrov wrote:

We have a Native Navision database (4.01)

Denis_Petrov

It stops right in the middle of creating key in the G/L Entry table. In my understanding all files have been read already, what file could be possibly accessed then?

Savatage

Are you sure the database you created is big enuf to hold the restore and the building of keys?

DenSter

:oops: sorry it appears there is some sand in my eyes....

Denis_Petrov

Savatage wrote:

Are you sure the database you created is big enuf to hold the restore and the building of keys?

Increased it by 10% - still same issue... ](*,)

still trying...

any other ideas?
Thanks

Denis_Petrov

is there a consulting firm /person out there we can call and get the issue resolved? This is really urgent!

THANKS!

garak

Do you have also the original database (before changing / creating the backup) files or only the backups :?:

Can you restore the backup on a other server :?: It could also be (Error message "The operating system cannot gain access to the file") that you have a problem with your NTFS file format.
Check the restore on a other server. Works this :?:

Denis_Petrov

garak wrote:

Do you have also the original database (before changing / creating the backup) files or only the backups :?:

Yes I do but the company I am trying to restore has been deleted. The restore of that (one) company fails on the stage of creating keys...

garak

i think that you has follow to the tip of Savatage......
If you restore a backup (for exampe with a space of 34 GB you need a empty database with a space of 80 GB or more....

garak

Can you restore the backup on a other server :?: It could also be (Error message "The operating system cannot gain access to the file") that you have a problem with your NTFS file format (hope u use NTFS and not FAT 32 ;-) ).
Check the restore on a other server. Works this :?:

David_Singleton

Denis Petrov wrote:

We have a Native Navision database (4.01) with 175 companies.
I have a complete backup, only 7 companies need to be updated (with most recent transactions done on a backup server).
So I took the original database and deleted those 7 companies. Tried to restore 4 so far, 3 companies worked just fine. Forth company ("X"), being the largest, gave this error message (while Creating Keys, the last step of the back up!):

The operating system cannot gain access to the file .
Please check that the file type and attributes are correct.

Why? :?: Three companies worked fine, so restore works for companies but not all? Any ideas?
](*,)

In Native this error happens a lot. (Well I have seen it happen a lot). I never really fond one cause, but here are some things off the top of my head that caused it.

Not enough disk space.
Probably the most common. NAV craetes a temp file when restoring a backup. I once did some tests and worked out the size, but cant rememebr, but think like the LOG file in SQL, in Native it does it on the local drive. Generally you need quite some free space. The reason for this is that in Versions up to 2.00 the keys were sorted in the database, and that meant you needed space in the database for the lagest possible keys 9twice) so becasue you had to pay for database space it was a major issue. So they changed it.

Fat vs Fat32 vs NTFS.
(see above) Sometimes when creating the keys, the OS repots disk full say if it reaches 2gig. The only solution is to have C: (or the temp file) on an NTFS drive.

Permission
Unlikely in your case, but sometimes its that you dont have permissions or enough Quota to the disk.

Read only backup
If you took the backup of a CD it will be read only. Sometimes at the end it trys to write somethign back and gives an error.

Last file missing
Unlikely since you would not have restored any companies, but it will give this message when it can't find the last file.

Wrong names for backup file
Sorry I can't even think of an example, but I always end my backup file name in 01, givein room for 99 parts. Sometiems if ther eis a date in there, or if the last number is say 8 or something similar, the last file may get a wierd number, and for some reason this is not found out untli the very end of the restore.


If I think of more I will add them.

BTW I have seen this error MANY times, and I thought all this knowledge was of no use anymore since we moved to SQL. I hope this helps.

David_Singleton

Denis Petrov wrote:

The operating system cannot gain access to the file .
Please check that the file type and attributes are correct.

By the way that "." in the error message and the " " before it really are the key. Its great that you posted the EXACT message, because that " ." is important. I think they envisioned that the OS woudl return some usefull information to put in there, but it doesn't.

David_Singleton

David Singleton wrote:

Not enough disk space.
Probably the most common. NAV craetes a temp file when restoring a backup. I once did some tests and worked out the size, but cant rememebr, but think like the LOG file in SQL, in Native it does it on the local drive. Generally you need quite some free space. The reason for this is that in Versions up to 2.00 the keys were sorted in the database, and that meant you needed space in the database for the lagest possible keys 9twice) so becasue you had to pay for database space it was a major issue. So they changed it.

Just thinking, this cahnged quite a bit as to where the temp file was created. At one stage it was onthe client but then moved to the server. So it might be space on the folder on the server where SERVER.EX is installed. It could be on the local client. Then again you also need to check which temp folder.

Anyway what you need to do if you cant find it, is to start the restore, and have all the drives open in folders, and hitting F5 to see which one starts growing.

Or just delete everything you can and make space.

garak

i know, that there was a problem with an version (was it a 3.xx or a 4.xx) if you restore a database from a network path name \\servername\ or was that with the hotcopy application :-k , mhm my notes are at work, damned

garak

try the restoring on a other fast server or directly an the server not over LAN

To check the space on the drives as David sayed is also an starting point

ta5

David Singleton wrote:

Wrong names for backup file
Sorry I can't even think of an example, but I always end my backup file name in 01, givein room for 99 parts. Sometiems if ther eis a date in there, or if the last number is say 8 or something similar, the last file may get a wierd number, and for some reason this is not found out untli the very end of the restore.

We once had a weird problem when the directory containing the backup files had a number in its name.

Thomas

David_Singleton

Denis Petrov wrote:

is there a consulting firm /person out there we can call and get the issue resolved? This is really urgent!

THANKS!

Did you get this resolved?

Sorry but its just a little annoying when someone has an issue that clearly is urgent, they get lots of replies of help, and then vanish?

At least out of curiosity I would like to knwo what the issue was in the end.

Denis_Petrov

Dear David and wonderful Navision community!

From the bottom of my heart I would like to thank you for helping me (and my great non-profit organization ) in the time of need. This was one of the crucial project in my 7 year career and it is so nice to have a world-wide think tank to help you.

It was the disk space on C: drive (which we reserve for OS system and other crucial processes only, native database is stored on 4 other physycal drive that are on RAID (which bring total number of drives to (1+4)x2=10)

So if you have less than 2 Gb on the C: hard drive while restoring a database size of let's say 60 Gb to OTHER disks - you run into troubles. Please be aware and have enough space (in my case 4 Gb on C: solved the problem).

Thank you again!

Sincerely

Denis Petrov
New Orleans, LA, USA

David_Singleton

Denis Petrov wrote:

Dear David and wonderful Navision community!

From the bottom of my heart I would like to thank you for helping me (and my great non-profit organization ) in the time of need. This was one of the crucial project in my 7 year career and it is so nice to have a world-wide think tank to help you.

It was the disk space on C: drive (which we reserve for OS system and other crucial processes only, ....

Great to see its resolved.
\:D/

Not only for the satisfaction point of view of knowing there is another happy cusotmer out there, but importantly it strengthenths the community knowledge base.

Glad to see that all my old C/SIDE database knowledge is at least a little bit of use before it all gets replaced by SQL.

garak

god to know that you have solved this . =D>

@David: some importend informations are ever stored in the brain ;-)

kriki

[Topic moved from 'NAV/Navision' forum to 'NAV Tips & Tricks' forum]