Tech. Upgrade 4.03 -> 6.0R2

MartinFK

Hi,

If I am right, to technically upgrade a database from 4.03 to 6.0R2, you can:

1. open the 4.03 database with a 6.0 client
2. NAV backup 4.03, create empty database with 6.0 client, NAV restore into new database with 6.0 client

Is the result the same?
What do you recommend?
Are there any other possibilities?

We have a 250GB+ database and doing (2.) takes more than a whole weekend. Which will be a problem for the live database.


Thanks for you comments.

(currently on W2003/SQL2005, moving to W2008R2/SQL2008R2)

ara3n

Same results, but you need to compile all the objects and fix them. Also case statement are case sensetive so there are two forms that use case statement and you need to load the 6.02 objects or just change the object from code to text.

I've done this for a client that needed webservices and they are running for about 1 year now without any issues.
4.0 sp3 db with 2009 Sp1 exe.

MartinFK

Thanks for your quick reply.

Did you do performance tests and crosscheck the main workflows or is this procedure bulletproof?

stryk

MartinFK wrote:

Thanks for your quick reply.

Did you do performance tests and crosscheck the main workflows or is this procedure bulletproof?

This is something you need to do anyway - regradless about how you technically performed the upgrade!

If you upgrade via FBK this will take ages - I've seen cases where a weekend was not time enough for such a proceeding ...
Also, all kinds of SQL optimzations & features (satistics, custom indexes, etc.) will vanish. A FBK cannot backup Vies, Procedures or any other SQL object.
When restoring a FBK you create everything from the scratch - that's like FORMAT C:\ and reinstall erverything. To make a long story short: FBK with SQL Server sucks.
Just opening the db with the new client will just "convert" it, means the SIFT are replaced by VSIFT and some system objects are changed (and little more).

Regarding performance:
Just upgrading your database technically will NOT automatically solve all your problems! Of course, advanced NAV 2009 R2 technology provides smarter features and behaviour than older NAV versions, but you need to make sure that your APPLICATION is taking advantage of those! And still it is NAV, thus there's always some tuning required ...

So again: test your upgrade ... test your upgrade ... test your upgrade ...

MartinFK

Hello Jörg,

thanks for your reply.

My question was aiming, if NEW problems arise due to the conversion.

I am aware that existing issues will not disappear because of the upgrade.
And additionally testing is key - totally agree with you.

After test-converting the database with the client, I still have some tables (e.g. Landsteinar Retail xxx$99001472$1) that represent SIFT.
How to handle this? Leave it?

Is there a description/blog/... available, what changes are applied during this conversion?
You mentioned some system tables for example.

I will do a recompile after the conversion.
What else should be considered?

Thanks,
Martin

stryk

Well, it is not unusual that some old SIFT stuff remains after conversion ... but I don't know the reasons for that ... this is an issue you probably could ignore ... maybe you could try to delete those SIFT tables manually?!

Generally it is possible that new problems arise. The "finsql.exe" is a different one, basically designed to improve, but of course there could be various issues ... check the KB or Waldo's Blog about NAV Builds for evidence ...

Since NAV 4.0 SP3 there have been a lot of enhancement like Buffered Inserts, Cursor Preparation, VSIFT, OPTIMIZE FOR UNKNOWN, etc. but any of them could also fire back (in few cases, but it could happen). Most important, the new NAV versions are using "Dynamic Cursors" - this makes the SQL Server behave differently to the older NAV versions, in most cases for the worst ...

So YES, there could be new problems - the only way to find out which affects YOUR system is to test!
Have in mind that most problems could be fixed, of course.

ara3n

Yes we had old sift table left in the db, but we deleted them through sql sms.