Low performance with rapidstart in NAV2018

Hi everyone,

I’m finding a extrange problem in NAV 2018 that it’s driving me mad, I upgraded a customer’s server from 23013 to 2018. In 2013, rapidstart was workimng perfeclty, but in NAV20418, we’re finding performance issues. For example, a package from a table with 2 records, and 600 occurrences, it takes over 10 minutes when applying the package. When I import he excel, it is really wuick, but the problem appears when I apply the package, it takes too long as you can sse, and Navision stays in “Not responding” until the process ends.

This procecss should be realy quick, more gicen that this process, in NAV2013, with a worse server, was working perfectly.

has anyone found this issue? It’s a known problem? How can be improved the performance of rapidStart?

Thank you very much

Which versions are 23013 and 20418? [emoticon:4191f5ee34e248a29fa0dbe8d975f74a]

Yes, it’s a known issue that RapidStart somethings should have been called SlowStart. Not particularly in NAV 2018.

But if its as slow as you say, then there may be more wrong. If it happens when you are inserting data, then the problem may actually be in the tables you are inserting to. Do you just insert, or insert and validates?

Try to run it with the debugger, to see if there are any problems in your code.

Thanks Erik,

The problem is generalized. For example, I’ve created a new table, with 2 fields, without any validation. Just to load the old and the new code for a few products, and then with an easy procees, to change the codes for those products.

So, one table, with 2 fields, and exactly 633 records. But as I commented before, it happens with any configuration

What I’m gonna explain, I know it’s gonan sound really extrange, but it is what it is. I will try to explain the most especific possible

The apply button, call to the “ApplyPackage” function from CodeUnit 8611:

TESTFIELD(Code);
IF CONFIRM(Text003,TRUE,Code) THEN BEGIN
  ConfigPackageTable.SETRANGE("Package Code",Code);
  ConfigPackageMgt.ApplyPackage(Rec,ConfigPackageTable,TRUE);
  //ConfigPackageMgt.ApplyPackage2(Rec,ConfigPackageTable,TRUE);
END;

As you can see, I’ve created a “ApplyPackage2” function. This is the same function brought from NAV2013. When I run again the “Apply”, with the NAV2013 function, it runs really fast, but when it ends, I see this message:

2018-06-06 11_12_59-BaseMet-2018 - 217.127.111.3_5501 - Conexión a Escritorio remoto.png

ANd also can be seen, that the records from the package, haven’t been deleted:

But the table has been correctly loaded.

As fgar as I understand, it seemes that the process that it’s taking too long is the one that deletes the records from the package…

Without being able to see your code - then it’s very difficult to give you more than a few suggestions to check…

  1. In your code where you delete a number of records - Are you using a proper sorting key (A key that contains the filter you are setting when you do your DELETE/DELETEALL

  2. Your %3 and %4 is because of the Message/window-type DIALOG is missing an Window.Update(3,Value) and Window.Update(4,value)

Thanks for your answer palle:

I’ve already solved the issue of the message.

This is my code:

ConfigPackage.CALCFIELDS("No. of Records","No. of Errors");
TableCount := ConfigPackageTable.COUNT;
ErrorCount := ConfigPackage."No. of Errors";
IF (TableCount = 0) OR (ConfigPackage."No. of Records" = 0) THEN
  EXIT;

CleanPackageErrors(ConfigPackage.Code,ConfigPackageTable.GETFILTER("Table ID"));

IF SetupProcessingOrderForTables THEN BEGIN
  SetupProcessingOrder(ConfigPackageTable);
  COMMIT;
END;

DimSetIDUsed := FALSE;
IF ConfigPackageTable.FINDSET THEN
  REPEAT
    DimSetIDUsed := ConfigMgt.IsDimSetIDTable(ConfigPackageTable."Table ID");
  UNTIL (ConfigPackageTable.NEXT = 0) OR DimSetIDUsed;

IF DimSetIDUsed AND NOT DimSetEntry.ISEMPTY THEN
  UpdateDimSetIDValues(ConfigPackage);
//aitor<<
IF (ConfigPackage.Code <> MSGPPackageCodeTxt) AND (ConfigPackage.Code <> QBPackageCodeTxt) THEN
  DeleteAppliedPackageRecords(TempAppliedConfigPackageRecord); // Do not delete PackageRecords till transactions are created

COMMIT;//esto va siempre

TempAppliedConfigPackageRecord.DELETEALL;
TempConfigRecordForProcessing.DELETEALL;
CLEAR(RecordsInsertedCount);
CLEAR(RecordsModifiedCount);
ConfigPackageTable.SETRANGE("Parent Table ID",0);
//aitor>>
ApplyPackageTables(ConfigPackage,ConfigPackageTable,ApplyMode::PrimaryKey);
ApplyPackageTables(ConfigPackage,ConfigPackageTable,ApplyMode::NonKeyFields);

ConfigPackage.CALCFIELDS("No. of Errors");
ErrorCount := ConfigPackage."No. of Errors" - ErrorCount;
IF ErrorCount < 0 THEN
  ErrorCount := 0;
RecordsModifiedCount := MaxInt(RecordsModifiedCount - RecordsInsertedCount,0);
IF NOT HideDialog THEN
  MESSAGE(NoTablesAndErrorsMsg,TableCount,ErrorCount,RecordsInsertedCount,RecordsModifiedCount);

Seems that I’ve solved it putting

ProcessAppliedPackageRecords(TempConfigRecordForProcessing,TempAppliedConfigPackageRecord);
IF (ConfigPackage.Code <> MSGPPackageCodeTxt) AND (ConfigPackage.Code <> QBPackageCodeTxt) THEN
  DeleteAppliedPackageRecords(TempAppliedConfigPackageRecord); // Do not delete PackageRecords till transactions are created

After the “ApplyPackageTables”

Hi Erik,

in fact this problem exists and is very annoying.

Especially when the database is quite big already, Rapidstart is not performing at all.

At the end of the Import, an event is raised: ApiSetup in CU5465 “GraphMgt - General Tools”.
This event is handled by a number of other codeunits in the same area (30 times).

A lot of database modifications starts off from here.

The same code runs over and over (whenever you apply the package).

So even if your package just contains one table with two fields and one record in this table. Rapidtstart takes 30 minutes or more to complete. (The more customers, invoices, payments and so on you have, the longer it takes).

Yes Thomas, you are very right. I have after this thread, then I have seen reports about it in several places and heard it from other consultants.

I would suggest to check in the release notes to newest CU’s.