Eliminate or reduce the need to continuously “Connect to Server…” within Visual Studio 2012
I find it extremely frustrating that each time I want to run SQL Prompt against a new query window (within Visual Studio 2012) I’m forced to “Connect to Server…” Is there no way to inherit the current connection made when opening a new query window or an existing stored procedure?
I’ve been an avid user within SSMS and would like to make the transition to working within SSDT projects. This is definitely a deterrent to using SQL Prompt within Visual Studio.
We’ve released SQL Prompt 6 which includes a fix for this.
This is so much better. Thanks!
Thanks for letting us know Curtis!
It looks like build 260 had a buggy shared library in it which broke our about dialog box and "qualify object names" so we've just released 270 (same url as before) which I’d recommend upgrading to.
Curtis Hebbard-Langille commented
Works great, thank you so much for addressing this issue!
In VS2012/SSDT prompt should inherit the connection from the query automatically. Before this update you’d have to manually tell SQL prompt that you wanted suggestions from a server/database (through the menu SQL Prompt->Connect to Server…).
Is this not the case for you?
Aaron Bauman commented
Aaron Law - I just installed 126.96.36.1990 and after poking around, I guess I'm just wondering what I should be seeing for this update? What exactly did you guys do?
Aaron Bauman commented
How about shortcuts to switch connections? We type out "USE <database>" to switch to a database. Is there something we could quickly hammer out to jump connections?
Favorites? There are 2 databases I use daily, one click changing of connections would be excellent.
AdminDavid Atkinson (Admin, Redgate) commented
Avoiding repeated connections is something we'd love to add as soon as we start the next SQL Prompt project, so please bear with us. We acknowledge that the current experience is less than ideal. Regarding supporting auto-prompting based on the database project, it's a bigger change due to the current architecture of the tool, but may be something we consider as more of our tools gain compatibility with SSDT database projects. The latest versions of SQL Source Control and SQL Compare can work with this database project format.
While I agree with Adam that, in the end, it would be more beneficial for users in Visual Studio 2012 to have SQL Prompt use the SSDT solutions/projects as its source, I think this is a pretty big departure from the product as it works today.
Perhaps it would be easier and a quicker time to market solution to have the add-in keep a persistent connection for all files opened. It would definitely save me a lot of time not having to connect for each file I open.
Regardless, Visual Studio with SSDT is becoming a much better environment for larger development projects with superior source management, better compilation and more viable deployment options than anything we've seen before. I would love it if Redgate would support it with the same level of excellence that we've seen in the product while using SSMS.
Another way to address this problem, for us at least, would be to not require a connection at all! All of our tables and relationships are already defined in the database project. This is the most up-to-date schema. To be honest, I'd rather have suggestions from the schema in the database project instead of using what had been published into the database however long ago.
The best case solution for us would be to have suggestions from both the VS database project AND a connected database (after entering credentials only once per session, of course), but list suggestions from the database project first.
I am as well trying to move my SSMS development to SSDT in Visual Studio for having a superior interface, editors and project organization. It is very frustrating to connect SQL Prompt to the database each time a file needs to be edited.
It would be nice to have an option similar to SQL Search where a number of different connections to servers and databases are maintained. If you need to work on a different connection you would go and change database or server. This option would be a great help when working in a disconnected mode on the database project.
In case you work in the connection mode in Visual Studio it should be able to deduce from the current connection which database to connect to.
Brett Phipps commented
I don't understand why SQL Prompt doesn't just use the same connection that I created for the query window itself. I'm making the transition from SSMS to Visual studio because the layout options are superior to SSMS and it took me a week to realize that I had to do a separate connection to SQL Server for SQL Prompt. I was about to throw the whole damn thing out the window because VS is getting better at prompting all the time.
This is a major problem the way it is. For a particular task, I'm not only working with multiple stored procedure and function files, but I may also be closing and reopening them as I work. I can't be expected to log in 10-20 times per task.
There needs to be an option to have the connection persist at the project, solution, or VS instance level.
Also, I only ever work with one copy of a production database locally so the ideal scenario for me would be to supply my credentials once and have SQL Prompt automatically connect to that database when I open a project so I NEVER have to click 'connect' again.