How can we help you today? How can we help you today?
isme
Activity overview Badges (0) Posts (22) Comments (28)

Comments

Sort by recent activity
This issue has been reported already on Uservoice: Simplify datalink source code repository migration. We ran into 4 issues: 1) When opening SSMS for the first time, we were inundated by SQL Source Control to update our credentials. 2) After hitting cancel 10 times, we were able to get to the Setup tab. ... My new suggestion on Uservoice proposes a solution: Suppress credentials prompt when SSMS starts. Can you suppress the dialog on startup? It would be better to ask only when it is really necessary, like when I want to sync the database with source control. The change would be a small but significant usability improvement. Thanks, James! / comments
  1. Community
  2. SQL Source Control Previous Versions
  3. Credentials Dialog Reappears After Cancelling
This issue has been reported already on Uservoice: Simplify datalink source code repository migration. We ran into 4 issues: 1) When opening SSMS for the first time, we were inundated by SQL Sourc...
0 votes
SQL Test is a lot more robust with this update. It remains stable when the long test runs. There are no messages about timeouts in the GUI. The stop button does indeed stop a test in progress. The time to stop the test seems to depend on how long the test has been running. That's just normal rollback behavior, so that's okay. Because the program name is "Red Gate Software Ltd SQL Test 1.5.0.79", it's much easier to debug now. To find all the SQL Test sessions, you can use a query like this: SELECT spid, program_name, cmd FROM sys.sysprocesses WHERE program_name LIKE '%SQL Test%'; Sorry for my late reply - been away from development projects for a while. Thanks for tackling this, David! / comments
  1. Community
  2. SQL Test
  3. Long-running test crashes SSMS
SQL Test is a lot more robust with this update. It remains stable when the long test runs. There are no messages about timeouts in the GUI. The stop button does indeed stop a test in progress. The ...
0 votes
Thanks, Brian! / comments
  1. Community
  2. SQL Test
  3. Long-running test crashes SSMS
Thanks, Brian!
0 votes
Brian Donohue wrote: It looks like a situation we may not be able to work around. [...] [SQL Test] can't cancel a query that is running whilst in-progress, unfortunately. SQL Server does not impose that behavior. You can work around it by changing how SQL Test manages its sessions. SSMS allows you to cancel a query that is in progress. You can press the red stop button, or close the window. If you close the window, you have to answer "Yes" when it asks "Do you want to cancel the query?" It's not a major issue, but I would be happier knowing that my careless coding can't crash my client. / comments
  1. Community
  2. SQL Test
  3. Long-running test crashes SSMS
Brian Donohue wrote: It looks like a situation we may not be able to work around. [...] [SQL Test] can't cancel a query that is running whilst in-progress, unfortunately. SQL Server does not i...
0 votes
Thanks, Brian. Are you referring to the output I posted? Sounds like you might be referring to a different set of spids. The exact numbers will vary from time to time. Brian Donahue wrote: SQL Test's process, according to the who query, is SPID 56. Cancelling SPID 54 is killing a generic SQL process, so there is no control over what will happen when you try to kill the SPID. It seems to cause an "Internal Binder Error" in the SSMS process. Not sure what you mean by "generic SQL process". In my example, spid 54 must be the SQL Test process. Everything else is idle ("AWAITING COMMAND") while the test is running. The program_name column contains nothing like "SQL Test". SQL Test apparently uses the SSMS default program_name ("Microsoft SQL Server Management Studio") instead of identifying itself clearly. The program_name of SPID 56 is SQL Prompt, not SQL Test. I don't think SQL Prompt is causing any issue here. I should have disabled it to make the output clearer. SSMS is generally quite robust, but it is not protected from crashes caused by add-ins. To clarify, it looks like SQL Test is crashing and taking SSMS with it. SQL Prompt is more robust. It doesn't crash SSMS if its spid is killed. It just stops working until you turn it off and on again. Could you make SQL Test behave the same way? / comments
  1. Community
  2. SQL Test
  3. Long-running test crashes SSMS
Thanks, Brian. Are you referring to the output I posted? Sounds like you might be referring to a different set of spids. The exact numbers will vary from time to time. Brian Donahue wrote: SQL Tes...
0 votes
Can you add the exit code to the documentation for version 2 as well? That's the version we actually use on the TeamCity build agents. http://documentation.red-gate.com/displ ... mmand+line / comments
  1. Community
  2. SQL Doc
  3. What does exit code 70 mean?
Can you add the exit code to the documentation for version 2 as well? That's the version we actually use on the TeamCity build agents.http://documentation.red-gate.com/displ ... mmand+line
0 votes
The documentation now says "70: Internal Software Error. Please contact Support." Yikes! Thanks, guys, I'll follow up the support ticket. / comments
  1. Community
  2. SQL Doc
  3. What does exit code 70 mean?
The documentation now says "70: Internal Software Error. Please contact Support." Yikes! Thanks, guys, I'll follow up the support ticket.
0 votes
james.billings wrote: in my case, this didn't stop the extended properties from getting updated so I'm not sure that the cause of that is necessarily the same. What was the type of the last object in your sync script? I can reproduce your behavior if the last object is a table. CREATE TABLE x (y INT); DECLARE @RG_SC_VERSION BIGINT SET @RG_SC_VERSION = 123 IF EXISTS (SELECT 1 FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL)) EXEC sp_dropextendedproperty N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL EXEC sp_addextendedproperty N'SQLSourceControl Database Revision', @RG_SC_VERSION, NULL, NULL, NULL, NULL, NULL, NULL GO The intention of this batch is to create table x and set the version property to 123. The batch separator is missing, but it behaves as you expect. It's not possible for the non-schema statements to be part of the table definition, so SQL Server creates the table then applies the extended property. You can see that it worked when you query the database metadata. /*------------------------ SELECT name, create_date FROM sys.objects WHERE name = N'x'; SELECT name, value FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL) ------------------------*/ name create_date ----------------------------------- ----------------------- x 2013-12-04 11:41:48.390 name value ----------------------------------- ------------------------ SQLSourceControl Database Revision 123 One table was created, and the extended property was updated. Perfect! But there's a problem when the last object is a stored procedure. CREATE PROCEDURE y AS BEGIN SELECT 1; END; DECLARE @RG_SC_VERSION BIGINT SET @RG_SC_VERSION = 456 IF EXISTS (SELECT 1 FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL)) EXEC sp_dropextendedproperty N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL EXEC sp_addextendedproperty N'SQLSourceControl Database Revision', @RG_SC_VERSION, NULL, NULL, NULL, NULL, NULL, NULL GO This batch looks like it creates stored procedure y and sets the version property to 456. Instead it creates a stored procedure that contains the code to set the property. The missing batch separator makes an important difference. A stored procedure definition begins immediately after the AS and continues to the end of the batch. The BEGIN...END is just syntactic sugar; SQL Server ignores it. You can see something is wrong when you query the metadata. /*------------------------ SELECT name, create_date FROM sys.objects WHERE name = N'y'; SELECT name, value FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL) ------------------------*/ name create_date ----------------------------------- ------------------------ y 2013-12-04 12:08:45.607 name value ----------------------------------- ------------------------ SQLSourceControl Database Revision 123 One procedure was created, but the extended property was not updated. Uh-oh! You can see the code we meant to execute is inside the stored procedure when you print its definition. /*------------------------ DECLARE @definition NVARCHAR(MAX) = (SELECT [definition] FROM sys.sql_modules WHERE OBJECT_NAME([object_id]) = N'y'); PRINT @definition; ------------------------*/ CREATE PROCEDURE y AS BEGIN SELECT 1; END; DECLARE @RG_SC_VERSION BIGINT SET @RG_SC_VERSION = 456 IF EXISTS (SELECT 1 FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL)) EXEC sp_dropextendedproperty N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL EXEC sp_addextendedproperty N'SQLSourceControl Database Revision', @RG_SC_VERSION, NULL, NULL, NULL, NULL, NULL, NULL If the last object is a table, then there is no problem with the sync script. If the last object is a procedure, then the object definition is mangled, and the version property is not updated. Is that enough information for you to reproduce the issue and avoid it in Migrations V2? Looking forward to the new version! / comments
  1. Community
  2. SQL Source Control Previous Versions
  3. Migration script fails to set DB rev, modifies SP instead
james.billings wrote: in my case, this didn't stop the extended properties from getting updated so I'm not sure that the cause of that is necessarily the same. What was the type of the last ob...
0 votes
In version control the migration script ends with a batch terminator and a blank line. ... INNER JOIN Customer.tbCustomer c ON cp.FK_CustomerID = c.PK_CustomerID END GO It looks like SQL Source Control strips the batch terminator before appending the non-schema statements when it prepares the sync script. / comments
  1. Community
  2. SQL Source Control Previous Versions
  3. Migration script fails to set DB rev, modifies SP instead
In version control the migration script ends with a batch terminator and a blank line.... INNER JOIN Customer.tbCustomer c ON cp.FK_CustomerID = c.PK_CustomerID END GO It looks like ...
0 votes
Thanks for the explanation, Brian. Manfred Castro filed bug SC-6447 where SQLCompare.exe ignores project filters. When the bug is fixed, it might be a good opportunity to update the documentation as well. / comments
  1. Community
  2. SQL Compare Previous Versions
  3. /project switch help is misleading
Thanks for the explanation, Brian. Manfred Castro filed bug SC-6447 where SQLCompare.exe ignores project filters. When the bug is fixed, it might be a good opportunity to update the documentation a...
0 votes
Total activity
64
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
14