Comments
Sort by recent activity
Hi Evan,
Thanks for looking into it.
Were you able to reproduce the issues?
Can you report on the internal status?
Thanks,
Iain / comments
Hi Evan,
Thanks for looking into it.
Were you able to reproduce the issues?
Can you report on the internal status?
Thanks,
Iain
In October Brian Donahue quoted a developer's explanation for bug 1.
If we delete a file, then the source control will just think that the file is missing, and will not delete it from source control when the changes are checked in.
Good version control tools can deal with missing files. It's a common scenario.
hg has the --addremove option which automatically removes missing files.
TortoiseSVN automatically deletes missing files that are checked for commit.
I think SQL Compare should not worry about what version control thinks.
When it's in script-writing mode, it should just concentrate on writing a tidy set of scripts. / comments
In October Brian Donahue quoted a developer's explanation for bug 1.
If we delete a file, then the source control will just think that the file is missing, and will not delete it from source contr...
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
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...
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
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 ...
Thanks, Brian! / comments
Thanks, Brian!
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
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...
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
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...
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
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
The documentation now says "70: Internal Software Error. Please contact Support."
Yikes!
Thanks, guys, I'll follow up the support ticket. / comments
The documentation now says "70: Internal Software Error. Please contact Support."
Yikes!
Thanks, guys, I'll follow up the support ticket.