We are attempting to upgrade LifeTime from version 11.27.2 to 11.28.2. After completing the installation, it is required to upload the new solution file through Service Center. During this step, we encounter a timeout error when updating the static entity records of the module 'LifeTimeCore'. To resolve the issue, we repeated the process multiple times without success. We then followed the recommendations in your support documentation by increasing the DDLLockTimeout to 1800 in the server.hsconf file, restarting all services, and updating the database statistics to improve performance. However, the issue persists. This problem is having a significant impact on our organization, as developers are currently unable to deploy to other environments.
Any ideas to resolve this issue ?
Hello Pedro,
Have you tried to increase the "Default Query Timeout" and "Database Update Query Timeout " values in Configuration Tool (instead of DDLLockTimeout) as described here?https://success.outsystems.com/support/troubleshooting/application_runtime/timeouts_under_the_hood/#sql-query-timeout
Hello, after i increase the "Database Update Query Timeout" , the upgrade ended without errors.
We ran into something very similar on one of our LifeTime upgrades.
Since you’ve already increased the DDLLockTimeout, restarted the services, and updated the DB stats, my guess is the issue may not be on the OutSystems side anymore.
A couple of things I’d look at:
I’ve seen larger LifeTime environments take much longer during metadata/static entity updates, so knowing the DB size would help.
Just curious, is the LifeTime database running on Azure SQL or a dedicated SQL Server?
If you’ve already checked all of the above, I’d probably open a support ticket with OutSystems and share the deployment logs plus an Environment Health Check report. The fact that it always seems to fail on the LifeTimeCore static entity update step feels like an important clue.
Can you share the SQL Server version and the approximate LifeTime DB size?
Hello Ankit Gangrade,
We check all your suggestions (the Sql resources , Sql blocking ) and everything is fine. Our Db has aprox. 81 Gb
If you still haven't been able to fix this, create a support case.