Thanks for the deatiled information.  This package is now open source and I added a PR to fix the issue of running migrations everytime.  You can test out the version here.

As for the other error you will need to disable automatice shema updates.

"EPiServer": {
        "CMS": {
          "clientResource": {
            "Debug": "true"
          },
          "dataAccess": {
            "databaseMode": "ReadOnly",
            "UpdateDatabaseSchema": false
          }
        },
}

Thanks for the quick response!

I've used the package EPiServer.Marketing.Testing with version 3.1.1-ci-87 and the problem is gone in the reproduction. We don't need to disable the automatic schema updates with this fix.

However, for our real CMS implementation (upgrade from CMS 11) we are still seeing the problem. Looking at the trace logs we see that the package/namepace EPiServer.Marketing.KPI is executing an SQL script at each startup (see log below). The 8 other SQL script executions are gone now, though. Those were from the EPiServer.Marketing.Testing.Web assembly/namepace.

dbug: EPiServer.Data.SchemaUpdates.Internal.ScriptExecutorImplementation[0]
      Execute Script: ''1.0.0.1.sql', 'EPiServer.Marketing.KPI, Version=3.1.1.0, Culture=neutral, PublicKeyToken=null', 'EPiServer.Marketing.KPI.SchemaUpdater.Kpi.zip'' 
trce: EPiServer.Data.Internal.MARSConnectionContextHandler[0]
      Using existing transaction

The reproduction doesn't execute this SQL script at startup. So there is something different between them. 

I've been looking at the source code and I think I have an idea of what's going wrong here. The logs point to a ScemaUpdater in the EPiServer.Marketing.KPI project. This does a call to GetDatabaseVersion with a Scema and a ContextKey, when I navigate the symbols down to the BaseRepository the ContextKey in the GetDatabaseVersion(string contextKey) doesn't get used. So takes the last version in the __MigrationHistory table, which likely is the wrong one. 

Yes sorry did not realize there were two schema updaters.  I pushed changes to the pull request and there is a new package version 3.1.1-ci-88, can you try that one.

Yes, the problem is now gone with the latest update. We can start our CMS 12 solution in read only mode while leaving the automatic database schema updaterer on.

I'm still wondering though whether the .LastOrDefault() is the correct solution on it's own. Currently the GetDatabaseVersion method just takes the last record on the __EFMigrationsHistory table, but this record may be from DbLocalizationProvider or something else, now it uses the number from the wrong migration to compare to whether do the migrations which might cause it to skip the migrations altogether on new installs. The CMS 11 version of this method has a .Where() to filter on the context key. I might be missing something here but it feels like it's still bugged although it's not causing an error at the moment. 

Yeah I will update both to take into account context key.

I updated the PR to use te context key.  If you dont mind testing one more time.  I will put 3.1.1 on the feed on on relase Tuesday if this solves all the issues.

I updated both the reproduction and the main solution to 3.1.1-ci-89, tested both with and without read-only mode enabled and I'm seeing no problems so far. It looks fixed from my end. 👍