FastLoadData field gets updated each time you persisted changes. So normally it must be none or few records with the null in the FastLoadData column.

Nulls would appear in the case of error during FastLoadData deserialization. Recently we had discover one possible reason of such an errors: DataObjects assumed that Type.GetProperties method returns PropertyInfos in the order properties defined in a class, but it is wrong. We had figured out that order PropertyInfos are being returned depends on e.g. what version of .NET runtime (32-bit or 64-bit) is currently running.

A consequences are really bad: Lets imagine two domains running in different environments(different .NET runtimes) but working with a same DB. FastLoadData produced by the first domain will differ from data produced by the second one and vice versa. Each attempt to deserialize wrong data in this circumstances will lead to error and nullifying FastLoadData field (Or even worse it would lead to reading wrong data!).

PS The error described is already fixed in our latest nightly build.

FastLoadData is set to NULL during upgrade for any entity which properties were touched by upgrade.

It gets automatically rebuilt further - during reads (materialization). The probability of FastLoadData update during read of each entity having FastLoadData==null is determined by Session.InconsistentDataUpdateProbability, its default value is 50 (50%).

So if such delayed update isn't desirable (that's actually pretty inconvenient in some cases, since it turns read-only transactions into read-write, and in general, increases deadlock \ version conflict probability), you should do the following after regular upgrade:

• Create a Session with Session.InconsistentDataUpdateProbability = 100
• Loop through all the operations below until the query there will return no objects:
• Start a transaction
• Run a query like "Select top 1000 DataObject instances where {FastLoadData} is NULL" (unfortunately, I don't remember exact v3.9 query syntax, so there can be a mistake)
• Enumerate all the entities there
• Commit a transaction.
• Probably, sleep for some period to decrease the concurrency, if this process runs in parallel with regular operations.

Hopefully, this will help.