Our NAV 3.60 system, runing on it’s native DB (.fdb files), was retired a little over two years ago before I arrived at the company. The live data was somehow imported in to our new ERP system (Vantage from Epicor, using SQL 2005 for its DB), however, we still need access to historic NAV 3.60 data so the old NAV system is still running as a virtual machine.
Of course the old NAV system is not covered by any sort of maintenance contract.
What would be great though is having all of the tables in the NAV db in a SQL 2005 DB so that I can easily report against it using the tools I have. Can the NAV DB be exported to a SQL 2005 DB (or even 2000) relatively easily without having to involve a third party or pay any sort of fee ?.
1.Make a backup from your old 3.60 client (fin.exe).
2.Run old 3.60 SQL client (finsql.exe) and restore the same backup to SQL DB.
Try whatever suggested by Modris, in addition if you get any error related to invalid dates etc., then there are some objects/ tools from microsoft that can help.
Please note that SQL doesn’t allow dates prior to 1753 (or so, don’t remember exact date though), and there may be entries in database prior to this date because of user typo/ mistakes. You might face some sorting issues also
Apologies for not coming back sooner.
Using the advice from Modris I can see what needs to be done, however, I’ve hit the problem that Dhan mentions.
The error I get is that the G/L Entry table has a row where the posting date is ‘26/01/0030’, so as Dhan states MS SQL can’t handle this.
Dhan, you mention that Microsoft have soem tools that coudl help me here, any chance you could point me in their direction please ?.
Also I’ve found this article…
… which states…
There is a code unit within Navision that will search all date fields in all tables looking for dates that would be considered invalid on SQL Server.
… can a kind soul exaplain how I might use the above ?.
Do you have access to PartnerSource? If not, then try at following link, you may find it here, it is a part of UpgradeToolKit in SQL Migration folder by Migration.fob name.
In case, that doesn’t work, send me your email ID by PM and I will email you the file. You need to import and run that codeunit and it will list the erroneous entries for you, which you can edit.
Thanks for pointing me in the direction of those tools. Earlier today I found this…
… and imported it, just like I have done with migration.fob. However, with both of these I get the error…
You do not have the permission to run the ‘xxx’ Report.
… which is odd and the user I’m logged on as has full right to the system, at least as far as I’m aware (I joined the business a few months after it migrated away from Navision, and what documentation there is is lacking.
Is the problem I now have an issue with my Navision license ?.
Yes, it is a license issue.
In the file downloaded from mibuso.com, use the text file and change the 79002 (use control+F and then replace) to the available number in your database (in 50000 series).
Damn, I thought that may be the case. I’ve followed your advice, and altered all references in the text file FieldCheck.txt from 79002 to be 50123. However, it still appears in Object Designer as 79002 (and I’m unable to remove the table or report). Why are things like this never easy
Basically Customers pay their partners, the partners pay fees to MS and MS use these fees to develop tools.
You are not going to (legally) get free access to do what you want. But really this is not a huge job, contact a Navision partner and pay them to do it. If the data is important then you will want it converted properly.
The other option is to use ODBC and connect in and copy out every table one by one. You work out which is cheaper.
I may have to bite the bullet and do this, it’s just that like many manufacturing compaines around the world our budgets are very tight right now so paying a consultant / partner may not be possible for many months to come
I’ve e-mailed a partner that we used many year ago to request their costs for converting our native DB to MS SQL, so far I’m waiting for their reply.
Our native DB when backed up comes to 658MB, so that should give people an idea of how large it is ?.
I’m more than happy for those that have commented on this thread, or others with the required skills, to PM (Private Message) me via this forum with their cost for converting our DB.
I have sent you an email, please check and revert.