Migration to SQL Server

Waldo

I have to do a migration to SQL Server (for the first time). Does anyone have tips & tricks to do this. I wanted to do following steps :oops: :

1) import migrate.fob from the CD
2) execute the codeunits
3) backup the database (dbsize = 3,5Gb)
4) create new database in SQL Server
5) restore in the new database

pankajmathur

It is quite simple to migrate to SQL server
All you need to do is take a complete back up of the Navision DB.
Open SQL Server option for Navision Attain
Goto Files and create new Database, also remember to check the option for storing the license in the database.
After you create the database, simply goto tools and restore the database which you backed up a while back.

Hope this works for you.

Waldo

I succeeded to do the migration, and indeed, it was not that difficult (you have to wait a long time, that's all).

Something vital though, is checking every piece of data with the migration.fob-file (on the CD), because that is going to check if the user-input was valid to SQL Server-specific demands. Especially dates are important. Suppose that the user was a bit too quick, and inserted date 01/01/0202 instead of 01/01/2002. Navision accepts the date, SQL Server does not. These, and a bit more checks are included in the migration.fob-file, and there is some functionality to automatically correct the data.

So, these checks done, and all objects are compiled, the migration should be done like pankajmathur said. Backup and restore in SQL Server Option.

Greetz!

MLW222

Hi
Have odd situation.
We use Navision Financials 2.00, if comes with no migrate.fob
Someone sent me a copy, which they reworked to work on 2.00 but it is missing codeunit 50015

So I have this black hole.
If someone could send me migrate.fob (as is) or the Codeunit 50015 part [either as a fob or in text format] I would very much appreciate it.

Doomhammer

Hi

Navision 2.0 does not work with SQL. you need first to migrate at version
2.50 or higher in order to use SQL option for NF

I can send you migrate fob from version 2.50

MLW222

Hi Doomhammer, (Martin)
Thank you

I realize 2.00 does not work with SQL
But I am using the migrate.fob for something a little different
I am basically going to use it to for the data it gathers.
Not going to actually migrate with it but it generates someusefull info.

We are migrating from Navision 2.00 to another software.
We are not migrating to Navision SQL server version.

So, please send me the migrate.fob

Thank you again.

medTUN

Hi,
I want also do a migration to SQL Server (Navision V3.60). But i'm affraid if this migration provoque some bug in programm's.

MLW222

A follow up

doomhammer sent me migrate.fob
1. watch it as it wirtes to/creates to some forms, table & codeunits, which are our case were already being used.
So you might need to go in and modify it so that it wirtes to blank objects.
2. for our purposes I was able to modify it to do what we needed, namely map out the tables & fields so that we could then map them to new system.

So thanks doomhammer.

Doomhammer

MLW222 wrote:

A follow up

doomhammer sent me migrate.fob
1. watch it as it wirtes to/creates to some forms, table & codeunits, which are our case were already being used.
So you might need to go in and modify it so that it wirtes to blank objects.
2. for our purposes I was able to modify it to do what we needed, namely map out the tables & fields so that we could then map them to new system.

So thanks doomhammer.

I am glad I helped you :-)

EWKrebbers

I am trying to do the same.
The previous version of navision is 2.01 and we are going to use 3.70

I made a backup in 2.01 and try to recover it in 3.70.
It takes a long time, and when it is almost finished, it concludes that some fields are not compatible with eachother.
Apparently the date values in Navision native database are not the same format as in SQL server 2000, so the recovery doesn't work.

Does anyone know a possible solution?

Thanks in advance

MLW222

Hi EWKrebbers,

I am a little fuzzy on the details at this point, but here goes.

When you run migrate.fob it creates a Table, numbered something like 50010.

In that table, it lists the "bad" data it finds.
It shows the Tabel & Field where the bad data is.

Depending upon your database size you could:
1. manually go thru and correct the data
2. write a report/codeunit to correct it.

"Bad" data?
e.g. Navision will accept a date like "02/02/0202" while SQL will not.
So depending upon what was inputted into navision you might have some bad dates [most common problem area]

I found some fields, in Navision, for decimals that actually were in this form "23.1234" thats is 3 or 4 places after the decimal.

So check for Tables created by migrate.fob and go thru the info there to find what needs to be corrected.

I forgot:
As I said fuzzy on the detail
When one runs migrate.fob when it is done it asks if you want it to auto-correct data.
I told it no, as I knew dates would be a problem and was not sure to what date it would correct.
Also, after it telling it no, I noticed the Table (50010?) listed a suggested correction.
If I remember correctly the suggested corrections were often just as bad as the original, e.g. wanted to correct 02/02/0202 to something like 02/02/0000 or such.

So if you had it auto-correct, it may have not done so properly.
Re-run and tell it not to auto-correct.

TheDude27

EWKrebbers wrote:

I am trying to do the same.
The previous version of navision is 2.01 and we are going to use 3.70

I made a backup in 2.01 and try to recover it in 3.70.
It takes a long time, and when it is almost finished, it concludes that some fields are not compatible with eachother.
Apparently the date values in Navision native database are not the same format as in SQL server 2000, so the recovery doesn't work.

Does anyone know a possible solution?

Thanks in advance

- Basically its telling you that you have a date in Navision that is outside the range that is allowed in SQL. Your version of Navision allows a much larger range of dates ie (1 to 9999). The problem is that someone entered a date like "0202" when they meant to enter "2002" . The year 202 not only dosent make sense but SQL can't handle it. You should have found this if you ran the date checking codeunit prior to upgrading. The "fix" is that you have to put valid data in the records that have problems. The upgrade codeuints allow you to do this easily.

- The other problem that you will encounter is that in 2.01 some of the objects have the same name (even though they have a different table/form number). Since SQL uses the name not the object number there are some problems with a few of the Payroll tables since Navision US localized it and kept the worldwide stuff in there as well. You will have to rename these.

- All of this can be avoided if you follow the upgrade procedures described in the documentation.