Upgrade from 2013 to 2018 - Upload of objects and cannot DROP index on Synchronize Schema


I am doing my first NAV upgrade to 2018. The current version is 2013.

With previous upgrades I have done, the steps have been typically as follows:

1.) Open the database in the new development environment/delete the old application objects except the tables.
2.) Import the Upgrade toolkit fob file.
3.) Run stage one of the toolkit fob file to move the data to the temporary tables.
4.) Upload the fob file containing the new application objects. Sync/recompile as required.
5.) Run the second stage of the upgrade toolkit.
6.) Delete the toolkit objects

Reading the 2018 upgrade notes, these state

“Import the application objects FOB file first, and then import the upgrade toolkit FOB file.”

Is this correct? Will this not affect standard fields in 2013 that are updated in 2018 if the 2018 table structure is changed before the upgrade tools are run?

I followed through the instructions on my test copy and then recompiled the objects as requested in the next section (Task 11: Compile all objects that are not already compiled) and got the following errors:

Table - 21 - Cust. Ledger Entry - The following SQL error was unexpected: Cannot DROP the index ‘First Company Name$Cust_ Ledger Entry.$7’ because it is not a statistics collection.

Table - 5802 - Value Entry - The following SQL error was unexpected: Cannot DROP the index ‘First Company Name$Value Entry.$12’ because it is not a statistics collection.

I get the same message if I try to disable the secondary keys on the tables to try to overcome the error.

Many thanks in advance

It’s correct to import new fob before the upgrade toolkit if i remember correctly.

There is a step or steps you are missing it seems.

The steps are correct, but expect that your database objects are unmodified.

if you have modified the standard tables, then you also need to add the modifications (like new fields) to the the upgrade toolkit. If you don’t then will fail no matter which order you import them in.

Thanks Imran and Erik for the feedback. We managed to find a solution to this. As this starts off as a 2019 database, we were able to resolve the issue by running a native NAV backup, which is still a feature of NAV2013, and restore it to a new database. this cleared the SQL index issue.