Comments
8 comments
-
Hi TonyStrileckis,
The size of the database itself wouldn't cause an issue (unless you are trying to store a lot of it as static data) but rather the number of objects would be more likely to cause an issue. Do any of the suggestions on this page help at all https://redgatesupport.zendesk.com/hc/en-us/articles/360007219153 ?
If you are changing and committing the comparison option to not "Decrypt encrypted objects" then I wouldn't have thought that would be the issue as it should be using the new option once committed.
If you set the logging option to "DEBUG" or "ALL" as described on this page and then recreate the issue there may be some info in the log file at %LocalAppData%\Red Gate\Logs\SQL Source Control
Also, having a look in the Event Viewer to see if there are any related messages may help.
Kind regards,
Alex -
Alex,
Thanks for your response.
I checked the link you provided and here are the answers to the steps on that page:- I am already on SSMS 17.9
- I'm not linking any static data tables.
- I have already tried unlinking and re-linking (twice)
- And the "Decrypt encrypted objects" option is already unchecked
- Last option was that I unchecked the two options of "Indicate changed objects...every x seconds" and "Check for changes to static data", and then restarted SSMS.
After restarting SSMS, I tried again with that database, but it still crashes.
I tried setting the logging option to "All", and a lot gets written to the logs, but nothing gets written to the logs after I select the server and database to check.
I tried setting the logging option to "Debug", but again it doesn't capture anything relating to the crash.
Here's what gets written to the logs after setting the logging option to "Debug" (or to "All"), but it gets written as soon as I open SSMS, before I have selected a server or database to check in (and the same gets written to Event Viewer):
- System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host Nothing else gets written to the logs after SSMS times out.
- Faulting application name: Ssms.exe, version: 2017.140.17285.0, time stamp: 0x5b7c378f
- Faulting module name: clr.dll, version: 4.7.3062.0, time stamp: 0x5ab95217
- Exception code: 0xc00000fd
- Fault offset: 0x00157b77
- Faulting process id: 0x37ac
- Faulting application start time: 0x01d574992055fb96
- Faulting application path: C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe
- Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
- Report Id: e6c70cf5-e08d-11e9-80d4-005056b43df2
- Faulting package full name:
- Faulting package-relative application ID:
Tony -
Hi @TonyStrileckis,
Hmm, that 0xc00000fd error is a stack overflow. What OS and SQL Server version is this with as well?
And how many objects are there in this database? If needed would you be able to share the database (I would reach out via a support ticket with an https link to upload it if it was possible)?
Kind regards,
Alex -
Alex,
I am using SSMS ver 17.9 on Windows Server 2012 R2. SQL Server is installed, but not running on the server where I'm running Redgate SQL Source Control.
This database has:- 311 CHECK constraints,
- 23 Default constraints
- 3 FOREIGN KEY constraints
- 550 PRIMARY KEY or UNIQUE constraints
- 25 Scalar functions
- 5102 Stored procedures
- 67 System tables
- 7 Table functions
- 35 Triggers
- 559 User tables
- 20 Views
Unfortunately, I cannot share this database.
Thank you,
Tony -
Alex,
While checking on the number of database objects, I noticed that this database has a user-defined table type that is used in a function. Don't know if they exist in any of our other databases.
Would that cause any problems when checking in changes?
And if so, how do I work around that?
Thanks,
Tony
-
Hi @TonyStrileckis,
Apologies for the delay in getting back to you on this, I thought I had replied, but it seems either I didn't submit it or something else went wrong!
I've gone over it again and I can't see anything wrong with having a user defined table type - or at least it isn't breaking anything for me.
I know it's been a little while now, so it would be good to see if a) this is still an issue in the latest version of SQL Source Control and b) if there is anything else different with that database than another.
Kind regards,
Alex -
Alex,
Thanks for getting back to me. Yes, this is still an issue. I have SQL Source Control version 7.0.50.9962, having just updated to this version last week.
I don't see where there is anything different with this DB as to the others on this same server.
Is there anything in the SQL Source Control logs that I should be looking for? Or that I can send you?
Thanks,
Tony -
@TonyStrileckis
Since this is an issue with that specific database, it's very difficult for us to investigate without a copy of the database.
We can take a look of the verbose log in case there is anything useful and I'll reach out shortly by email.
Thanks.
Add comment
Please sign in to leave a comment.
Please let me know if there is additional information that you need from me.
Thank you.