By default, Engine tracks and records registration launch history. Having information about launch and exit times helps Engine detect concurrent launches, which is when a learner launches the same registration again before the original properly exits. Launch history also enables Engine to detect when it receives data from a course that has already exited. By detecting these events, Engine can stop bad data from overwriting the good.
This protection does come with a cost. Engine records information about each launch in the ScormLaunchHistory table, so the table tends to be one of the larger ones in an Engine database. Consequently, customers frequently ask if anything can be done to reduce the amount of space used by ScormLaunchHistory. It is possible to disable launch history logging by setting PlayerCaptureHistory to "false" and then truncating the ScormLaunchHistory table. However, due to the protection that launch history provides during runtime in modern Engine versions, we generally do not recommend this approach.
Instead of deactivating launch history altogether, you can use a built-in process that automatically removes launch history entries. To enable this behavior, set the tenant-level ShouldExpireLaunchHistory setting to "true". The ExpireLaunchHistoryAfterDays setting controls how long (in days) Engine retains records before they're eligible for deletion. The default for this is 30 days, which is usually fine. It can be set lower, of course. The value just needs to be longer than a launched course could reasonably be left open.
If you have accumulated a lot of data in Engine's ScormLaunchHistory table, you should exercise caution before enabling ShouldExpireLaunchHistory. Due to the table's size, Engine could execute several long-running DELETE statements. This could potentially lead to locks on the table and disrupt registration launches. Consequently, if you plan on enabling ShouldExpireLaunchHistory, it may be preferable to manually purge the table before beforehand. This could be during regularly scheduled downtime or a more complex, multi-step process:
-
Create a temporary copy of the ScormLaunchHistory table.
- Copy over only the records you care about from the original table to your copy. In most cases, these would be more recently updated records, ones within the range of what's configured for ExpireLaunchHistoryAfterDays.
SELECT *
INTO ScormLaunchHistory_COPY
FROM ScormLaunchHistory
WHERE update_dt IS NOT NULL
AND update_dt < @cutoffdate; -
Rename the original table to something else and the copy to ScormLaunchHistory. You do this in a transaction, so nothing can happen during the switchover.
-
Add the proper foreign keys to the new ScormLaunchHistory table.
-
At a later point, drop the old version of the table.
In any case, it is perfectly safe to remove old rows from the ScormLaunchHistory table, but they need to be old enough that they don't include any legitimately active launches.