Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjusting compatibility level to SQL Server 2019 causes the application to freeze #46

Open
MCIR opened this issue Mar 8, 2024 · 8 comments
Assignees
Labels
bug Something isn't working fixed 7.2.5? Needs verification in 7.2.5 + Needs further testing Specific issue is resolved but testing further to ensure its not happening elsewhere in the app

Comments

@MCIR
Copy link
Collaborator

MCIR commented Mar 8, 2024

After applying the 7.2.1.6 update on the client's computer, I adjusted the compatibility level in the database properties options tab from SQL Server 2008 to SQL Server 2019 and saved the changes as you had recommended, then tested how the application would run with the modified compatibility level.

The application opens with no issues but attempting to perform tasks results in the application freezing, followed by the display of about 2 or 3 error messages seen below. Despite logging out and back in to both the application and the SQL server, the problem has persisted.

image

image

To investigate if the freezing is related to the compatibility level changes, I replicated the process on my personal computer and got the same outcome. Attempting to perform tasks in the application caused it to freeze and showed error messages like the ones shown on the client’s computer. Reverting the compatibility level back to SQL Server 2008 on my personal computer, then restarted both the SQL server and application resolves the freezing issue.

Should the compatibility level be maintained at SQL Server 2008? Not sure how to address this issue

@christillman christillman added bug Something isn't working fixed 7.2.4? Needs verification in 7.2.4 + labels Mar 8, 2024
@christillman
Copy link
Owner

christillman commented Mar 8, 2024

I have the fix for fn_attribute_description, which is the source of this issue, in release 7.2.1.7. I also submitted feedback to Microsoft about the issue.

@MCIR
Copy link
Collaborator Author

MCIR commented Mar 10, 2024 via email

@christillman
Copy link
Owner

christillman commented Mar 10, 2024 via email

@christillman christillman removed the fixed 7.2.4? Needs verification in 7.2.4 + label Mar 12, 2024
@christillman
Copy link
Owner

I found a new compatibility problem this morning. Don't bother trying to set 7.2.1.7 to 150 yet. I got this message after clicking on a patient:

Message Severity: 4 - ERROR
Message Date/Time: 13/03/2024 06:52:06
Epro Version: PB Client 7.2.1.7 (10/03/2024)
Object Class: u_sqlca
Object Script: u_sqlca.check:0108
Error Message: SQL ERROR = (8632) SQLSTATE = 42000
Microsoft OLE DB Driver for SQL Server
Internal error: An expression services limit has been reached. Please look for potentially complex expressions in your query, and try to simplify them.

Rolling back to SQL 2008 compatibility solved it.

@christillman christillman self-assigned this Mar 12, 2024
@MCIR
Copy link
Collaborator Author

MCIR commented Mar 12, 2024 via email

@christillman
Copy link
Owner

I fixed the second problem I found, which was in fn_workplan_item_owned_by_2 called by sp_add_workplan_item. I found a workaround to avoid the same out-of-memory message. This fix will be in 7.2.1.9.

@christillman christillman added the fixed 7.2.1.9? Needs verification in 7.2.1.9 + label Apr 6, 2024
@christillman
Copy link
Owner

I've learned that Azure always maintains the most recent version of SQL Server in Azure SQL Database. So the version we are using in Azure is equivalent to SQL 2022. I have set the compatibility level in GreenOliveDemo on Azure to be 160, also equivalent to SQL 2022, so this would be a good place to re-test. Let me know if you do try it out.

I also set the environment to "Serverless" so while it may take a minute or two to get "warmed up", you should get better performance than with the DTU setting (without needing to manually change it). It also costs a bit less when idle. So your usage would also be a good test of the Serverless environment to observe how much it will cost.

image

@christillman christillman added Needs further testing Specific issue is resolved but testing further to ensure its not happening elsewhere in the app and removed fixed 7.2.1.9? Needs verification in 7.2.1.9 + labels Sep 21, 2024
@christillman
Copy link
Owner

The Serverless setting was using money for resources just to do its own backups, much more than the DTU level of usage. I set it back to 5 DTU for now. Let me know if you need to do any testing.

@christillman christillman added the fixed 7.2.5? Needs verification in 7.2.5 + label Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed 7.2.5? Needs verification in 7.2.5 + Needs further testing Specific issue is resolved but testing further to ensure its not happening elsewhere in the app
Projects
None yet
Development

No branches or pull requests

2 participants