Probably too late now, but IIRC this was one of the possible errors I got when the sumindexes on a table had got corrupted. For my example it was during V4 sp1 (the bad zero buckets time) and the numbering on the sumindex tables was (somehow) out of sync with the numbering Navision wanted to use. It seemed to be related to a sumindex that had 'MaintainSIFT=Yes' but no sumindex levels defined, an index on the Item ledger entries table. However, I never had that issue with V3.7 :-k
BTW: Renaming companies in SQL is very slow, if you have multiple companies in a database it gets very likely that it's quicker to backup the company, restore it to a Native database, rename, then copy it back to SQL.
That really depends on many things. It has to rename all tables that belong to the company, but it can go really fast. This is one of the very few things that NAV lets SQL Server take care of. I've seen a company rename on a 650 GB database take less than 10 seconds.
I've seen the upgrade to SP1 increase the rename time, as the system drops and recreates the indexed views. With larger table this can take some time. One system I support went from a few minutes to about an hour to rename.
Having sufficient transaction log space is critical during a rename. If the system needs to constantly expand the log during the rename it will add time to the process.
Okay, you've got me curious; I'm having a look at the profiler.
Well, nothing seems to take very long to run, Navision is just sending an awe-full number of SQL statements.
The main identifiable issue seems to be the object table; this testing database has a lot of companies in it and Navision looks to be fetching all the objects for every company. I expect the object table is scattered all over the disk in this DB so that's not so fast... Increase the object cache to 200000, that speeded it up a lot!
As for the V5 SP1 issues, Build 27368 or later (KB 957733) is supposed to improve that but I don't think you can get away from recreating the sumindex views in this case because SQL won't let you rename them at the same time as the table.
:-k For the object table thing, has anyone got a script laying around that'll move "Object" to the primary filegroup? Or at least something to ensure that it's all together in one lump on the disk?
Comments
Are you creating a new company & restoring a backup into that company??
Are you changin the name simply in Company Information??
What steps are YOU taking to get this error?
http://www.BiloBeauty.com
http://www.autismspeaks.org
Are trying to rename an existing company with many records.
Therefore simply want to change the company name for the new name, and at that time the error is reported.
BTW: Renaming companies in SQL is very slow, if you have multiple companies in a database it gets very likely that it's quicker to backup the company, restore it to a Native database, rename, then copy it back to SQL.
TVision Technology Ltd
RIS Plus, LLC
Having sufficient transaction log space is critical during a rename. If the system needs to constantly expand the log during the rename it will add time to the process.
Well, nothing seems to take very long to run, Navision is just sending an awe-full number of SQL statements.
The main identifiable issue seems to be the object table; this testing database has a lot of companies in it and Navision looks to be fetching all the objects for every company. I expect the object table is scattered all over the disk in this DB so that's not so fast... Increase the object cache to 200000, that speeded it up a lot!
As for the V5 SP1 issues, Build 27368 or later (KB 957733) is supposed to improve that but I don't think you can get away from recreating the sumindex views in this case because SQL won't let you rename them at the same time as the table.
:-k For the object table thing, has anyone got a script laying around that'll move "Object" to the primary filegroup? Or at least something to ensure that it's all together in one lump on the disk?
TVision Technology Ltd