Table schema changed after cursor declared [42000:[Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Could not complete cursor operation because the table schema changed after the cursor was declared.]
I have checked this article: https://support.esri.com/en/technical-article/000012156 but still not getting what I should do.
the SQL server is installed on the windows server (2012 R2 standard) which is of 32 GB RAM size.
SQL memory is set to max.
Any Suggestions like what i can do?
Please help its urgent.
Thanks is advance for help.
I am having this same issue on Windows Server 2012 R2 Standard also. Did you ever find a fix for this? Is there anyone out there with suggestions?
Hi,
No, I didn't find any solution of this error.
For regular server maintenance we restarted our windows server and this problem got solved automatically but this is not a permanent solution because after 1 month around we again got this error and we are back on the previous position.
We are also experiencing this issue at on our Prod SQL 2012 R2 server. Since this seems to be an issue that's popping up, I'm wondering if there's been a recent Windows update that's causing issues or something similar. We are troubleshooting the issue now and will post if we find a resolution.
I'm seeing the same type of errors.
This may be related to what you're seeing: Problem: ArcGIS clients encounter errors related to table schema changes, app domain unloading, or f...
I also found this workaround talking about setting the SLQ Server max server memory = 70% - 80%.
Error: Warning 999999: Table schema changed after cursor declared
I haven't had time to try either of these yet. I just found this info today.
FYI, I recently found that Windows Update was not automatically installing updates and needed manual permission to proceed. My server was behind 62 updates. Since getting the server up to date and after installing the latest version of Server and Portal (10.8.1) about a month ago, I no longer get these errors (fingers crossed).
Hi -was it your AGS server or SQL server that needed the updates? Or is it the same box?
In my case, I found that applying all pending Windows operating system updates (on the machine hosting the SQL Server) fixed the issue.
(I then went ahead and applied SQL Server updates as well, but it was the operating system updates that resolved it for me.)
This was with a host running MS SQL Server 2019, and two-and-a-half years after the previous post in this topic.