A full reload always starts by deleting all tables in the existing data model, and then runs the load script.
A partial reload will not do this. Instead it keeps all tables in the data model and then executes only Load and Select statements preceded by an Add, Merge, or Replace prefix. Other data tables are not affected by the command. The only argument denotes that the statement should be executed only during partial reloads, and should be disregarded during full reloads. The following table summarizes statement execution for partial and full reloads.
|Statement||Full reload||Partial reload|
|Load ...||Statement will run||Statement will not run|
|Add/Replace/Merge Load ...||Statement will run||Statement will run|
|Add/Replace/Merge Only Load ...||Statement will not run||Statement will run|
Partial reloads have several benefits compared to full reloads:
Faster, because only data recently changed needs to be loaded. With large data sets the difference is significant.
Less memory is consumed, because less data is loaded.
More reliable, because queries to source data run faster, reducing the risk of network problems.
Add the example script to your app and do a partial reload. To see the result, add the fields listed in the results column to a sheet in your app.
T1: Add only Load distinct recno()+10 as Num autogenerate 10;
The statement is only executed during a partial reload. If the "distinct" prefix is omitted, the count of the Num field will increase with each subsequent partial reload.
Add the example script to your app. Do a full reload and view the result. Next, do a partial reload and view the result. To see the results, add the fields listed in the results column to a sheet in your app.
T1: Load recno() as ID, recno() as Value autogenerate 10; T1: Replace only Load recno() as ID, repeat(recno(),3) as Value autogenerate 10;
The first table is loaded during a full reload and the second table simply replaces the first table during a partial reload.