First NAV 2013 R2 to NAV 2016 upgrade failing : The UPG Item does not exist

Rodtmclean

Hi,

I am having issues with a NAV 2013 R2 to NAV 2016 upgrade. It is failing with: -



It seems that the UPG Item table is empty and UPGItem.Get below is causing the crash: -



Has anyone come across this before?

Regards
Roddy








Regards
Roddy

Rodtmclean

Thanks Matt,

I answered yes to a question I shouldn't have, in a hurry! The upgrade has since been completed.

Regards
Roddy

hitt123

Sync-NAVTenant without -Force should be the solution but is not practicable in customer databases. In our update we came from NAV 2009 with many modules over 2013 and there are tons of unused fields in the upgraded database which are removed fine with Sync-NAVTenant -Force. For me the following modification of CU 104000 did the trick:

[UpgradePerCompany] UpdateItemNextCountingPeriod()
WITH Item DO BEGIN
IF FINDSET THEN
REPEAT
//Change++
//UPGItem.GET("No.");
IF NOT UPGItem.GET(Item."No.") THEN BEGIN
UPGItem."No." := Item."No.";
UPGItem.INSERT;
END;
//Change--
ForwardPeriodInfo(
UPGItem."Next Counting Period","Next Counting Start Date","Next Counting End Date");
MODIFY;
UNTIL NEXT = 0;
END;

matt_quelch

Hi Roddy,

Have you synchronised the schema after importing merged FOB and UPG FOB without forcing? If you force it nullifies the upgrade codeunit as it will just delete the field and so the upgrade codeunit will not copy the relevant field from Item to UPG Item I think. That was certainly my experince anyway!

If the sync fails validation then it mostly likely means you have deleted fields between old/new tables in this case I think you'll need an upgrade codeunit to handle the deleted fields (or delete them in the source database before the upgrade).

Regards,
Matt

Rodtmclean

Thanks Matt,

I answered yes to a question I shouldn't have, in a hurry! The upgrade has since been completed.

Regards
Roddy

swpolo

If any, the problem exist when running upgrade from 2013R2 to 2016.
If upgrade plan is changed. 2013R2 -> 2015 ->2016.
You should avoid this issue.

mansoor

im also getting same error message, can't we upgrade 2009 R2 to 2016 , actually my upgrade path is 2009R2 >>2013>>2015.

swpolo

The problem is in huge Microsoft NAV2016 DevClient bug which is not solving starting from 2016 cu0.
While nav-dataupgrade is running, Navision cannot copy data from old table to temporary.

DataUpgradeMgt.SetTableSyncSetup(DATABASE::Item,DATABASE::Table104067,TableSynchSetup.Mode::Copy);

So UPGitem is empty after this line
and error appears after

UPGItem.GET("No."); //line in UpdateItemNextCountingPeriod() procedure.

Roelof

I have the same problem. Is there any solution or is just save to comment out some code in CU-104050 that deals with the UPGItem.Get ?

Roelof

additional question: where in the code is the table being copied?

mikhael

Hi,

I am facing the same issue when upgrading from 2013 to 2017. Is there any other feasible solution than adding "IF" condition befofe UPGItem.GET("No.") ?

hitt123

Sync-NAVTenant without -Force should be the solution but is not practicable in customer databases. In our update we came from NAV 2009 with many modules over 2013 and there are tons of unused fields in the upgraded database which are removed fine with Sync-NAVTenant -Force. For me the following modification of CU 104000 did the trick:

[UpgradePerCompany] UpdateItemNextCountingPeriod()
WITH Item DO BEGIN
IF FINDSET THEN
REPEAT
//Change++
//UPGItem.GET("No.");
IF NOT UPGItem.GET(Item."No.") THEN BEGIN
UPGItem."No." := Item."No.";
UPGItem.INSERT;
END;
//Change--
ForwardPeriodInfo(
UPGItem."Next Counting Period","Next Counting Start Date","Next Counting End Date");
MODIFY;
UNTIL NEXT = 0;
END;

Juhl

Check that all items have Base Unit of Measure.

NavNab

hitt123 wrote: »

Sync-NAVTenant without -Force should be the solution but is not practicable in customer databases. In our update we came from NAV 2009 with many modules over 2013 and there are tons of unused fields in the upgraded database which are removed fine with Sync-NAVTenant -Force. For me the following modification of CU 104000 did the trick:

[UpgradePerCompany] UpdateItemNextCountingPeriod()
WITH Item DO BEGIN
IF FINDSET THEN
REPEAT
//Change++
//UPGItem.GET("No.");
IF NOT UPGItem.GET(Item."No.") THEN BEGIN
UPGItem."No." := Item."No.";
UPGItem.INSERT;
END;
//Change--
ForwardPeriodInfo(
UPGItem."Next Counting Period","Next Counting Start Date","Next Counting End Date");
MODIFY;
UNTIL NEXT = 0;
END;

Hello @hitt123

As you said Sync-NAVTenant is absolutely the right solution. But I don't agree when you say "It is not practical in customer databases". In fact, during test upgrades you should notice that there is some customized fields in standard tables and you decide which upgrade strategy you'll adopt:
1- You don't need this data any more => You clean specific data and when you will not have any issue when you apply your staging fob in NAV 2013 (Cronus objects),
2- You need to keep your specific data => You archive your data in temporary tables and you put it back to standard tables when you're in NAV 2016.

If you option 1 or 2 then you will not need to force tables synchronization in NAV 2013 => You will not need to modify the upgrade toolkit

I hope this will be helpful for you or anyone who's looking to upgrade to latest NAV versions.