I am curious, why Siemens is restricting the PlantSimulation users from using the SQLite in-memory database in shared cache mode.
Maybe to allow the user(s) to use SQlite in a more productive way in futurer, or even better to change PlantSimulation in a way, that the SQLite database functionality is basing on the sqlite3.dll provided on the SQlite webpage instead of compiling the sqlite source code directly into PlantSimulation?
Of course an update of the sqlite3.dll is subject to the user's own responsibility.
two reasons for that:
Do you have a use case where you would benefit from the shared cache?
Yes, definitely, it starts from observing more efficiently the database changes in the in-memory database and is also driven by seemlessly attaching some statistical analysis packages / environments for proper analysis of interim results and final results of simulation runs.
Matthias Heinicke from your company has attended the conference "Simulation in Production and Logistics" last week. He should be aware about the statistical challenges simulation is still facing (and PlantSimulation is not necessarily providing solutions for).
the shared cache mode of SQLite only impacts database connections from the same process.
This is not related to the use of SQLite in a DLL.
Do you have multiple connections to your database from one Plant Simulation process?
I need to trigger this issue again. In the meantime, also a 64-bit version of the most recent SQLite version dll is available at the particular website.
In addition, a shared memory functionality for proper validation and verification of the database statements and current data in the database from an external database browser like" DB Browser for SQLite" or "SQLiteStudio" starts to become inevitable for serious model development.