Upgrading Compressed tables

McCoy

I have heard that there is a problem upgrading compressed tables - Can anyone tell me what the problems are? I have a client with a 39Gig database that wants to upgrade from 3.10 to 4.0 SP1. We know that we need to compress files with entries from 1998 forward but I would like to know if we should do the upgrade first because of prolems with compressed tables - This will run forever if we don't compress first but am leary since I heard that there are issues with upgrading compressed tables. Help - Anyone? [-o<

ara3n

Yes I've heard this as well, but don't know the details. I've heard that MS themselves don't recomend it. So try to contact them. Also for the upgrade you need some serious hardware. Make sure you increase your client cache. Good luck

McCoy

Thanks for your reply. I have only been coding Navision for 9 months and this is my 3rd conversion in the past 4 months. I have found out how much it takes, at least this one does not have payroll. The last one had payroll and was from a highly customized 2.0 version - a real pain.

Also, I found not only cache but number of drives increases processing so I use at least 6 drives and up the cache as much as possible but found that a medium size client with payroll conversion can take over 40 hours to run (includes multiple steps and multiple companies) and this is after the object have all been converted!!

kriki

The fastest way to upgrade is to use a full-scale server-installation. And the fin.exe you have to run ON that server, not on another machine.
You can also disable some keys you don't need for the upgrade in the big tables. (You need to check out the codeunits for that) (I had to check out this for a colleague because a test-upgrade took 21 days. With 1 hour of checking out and disabling some keys, it dropped to 9 days ; to further fasting it, he had to use better hardware and it dropped to 3-4 days).

kriki

Hello Nancy McCoy,
Why did you send me an email? It is better to use the forum, so we share all the information. And sometimes someone else has a good hint. When sending personal messages for information, you won't get good hints from others.

If I remember correctly, the DB was over 10GB. But first they ran the upgrade on a client-PC with slow disks (only 1 for also the system) and without service. It is better to have as many disks as possible with a controller for each of them. DO NOT -- I REPEAT -- DO NOT USE RAID5. RAID 5 is not good for DB's. It is more for file-servers with a lot of reads and few writes.

What do you mean with compressed?
=>Date Compression : I don't think so (had only 1 or 2 hours to optimize the code and give some hints on optimizing other things).
=>Optimized tables? Yes, because it came from a restore (try to avoid this, and just open the DB with the new version and convert it. If this is not possible, copy the DB-files, open the DB with the old version, disable the unneeded keys (you need to study this and make some fobs for the real upgrade), then make a backup and a restore in a new DB. Restoring is faster, because he doesn't need to create some secondary indexes)

I don't remember if there were payrolls or not.

-another hint: Create your new-version objects in 2 versions : 1 with all secondary indexes and 1 with only the secondary indexes (and SIFT-fields) that serve for the upgrade of the data. It is faster to create the indexes at the end, then having to maintain them while the program is changing the records.

Shenpen

Why don't just time update for the beginning of the business year, and just export/import (and convert in Excel or Acces or with Perl scripts or whatever) the master data, without transactions? Looks much safer.