Restore fails at 84% from fbk file

Hi Navision Experts,

I am having this weird problem I haven’t encountered before. When I tried to restore an fdk file to a new database (running on SQL Server), it would quit at around 84%. By quit I mean Navision simply closes and there is no error message prompting me what happened. I tried restoring the same backup file on two different machines and was able to repeat the problem. However, when I tried to restore it to a Navision native database, it worked just fine. So I suspect that it may have something to do with SQL Server. Did anyone every experience similar situation before?

Thanks very much.

Scott

I have not seen this issue, but a few questions.

Are any messages being logged to the SQL Error Log or the System Log (event viewer)? Also are you creating the initial empty database (and log) large enough to complete the restore without relying on Auto-Expansion?

The SQL Error Logs can provide a wealth of information, although a lot of it can be cryptic. But, it can help in most of these situations.

When it quits, do you think that you will be able to physically be at the machine when it does it, so that you can see what table it is on when it happens? I know that if it is a long restore, this can be difficult to do.

Then, I would suggest that since it restores natively, maybe take another backup copy of the restored native database, then try to restore that copy on SQL. It could be some kind of corruption in a table or something.

Have you checked for disk problems? And, as mentioned, have you expanded both the database and logs to be the total size you will need them to be? The logs do need to be at least as large as the fully expanded data set.

Also, this a pain to do, but I’ve actually installed SQL on my PC and restored Navision to it so that I can test things. It may be the SQL installation itself.

Did you select the default options in navisoin on the “New Database” form?

I had a similar problem. I raised support incident with Microsoft. After around a month of e-mailing and sending CD-s it turned out that the problem was in 3.60 client. The suggested solution was to use 4.0 client with 3.60 database. I tried and it worked. Nevertheless I didn’t do it on production system since I’m planning to do full upgrade to 4.0 soon.

Regards

Danko

That is not really a good reply, and I would suggest you take it up with your NSC/VAR, as they really should have known better [:@]

3.60 had a lot of problems, amoungst them many “minor” SQL issues. Your NSC should have told you long ago to move to the 3.70 executables. Whilst there are quite a few complexities in moving to the 4.00 executables, going from 3.60 to 3.70 executables is very simple.

problem is that there is no 3.7 version for croatia (as far as I know…).
Here (Croatia or Bosnia & Herzegovina area), we have 3.6 and we had to go directly to 4.0… I’m not sure they made executables with croatia stxs and language pack for 3.7v.

Welll that of course puts a diffenrt light on it. Tehy really should have, since 3.60 was just a horible version, and 3.70 was brilliant. Much like version 1.2 and 1.3. The US was really hampered by running 1.2 when the rest of the world was on 1.3. That was a very bad decision back then.

To be honest, I have no idea why they skipped 3.7v…

Its an odd one to miss. The upgrade process was simple, and it just made more sense.