I thought I read somewhere that in 'denali' we would be able to place tables within management studio into logical folders. For example I have 20 tables releating to clouds, i could create a clouds folder and group the tables logical, thus i can hide/expand that folder to see the tables. Is this already done in 2008 r2? *Or did i read correctly and it will happen in denali?*
SQL Server Code-Named Denali (or likely to be officially named 2011), has released its CTP 1. Along with it is SQL Server Management Studio.
Within, as it stands today, you cannot organize tables into 'folders' for visual organization.
There are many 3rd party solutions which could implement such a feature but MS has not implemented in their tools yet.
However, here is a potential solution: Management studio does allow you to define a filter on the tables list. If you are working on one area you can right click on the table leaf and select filter. Maybe this will help to restrict your view to just the tables you are interested in working with at a given time.
Related
hope everyone are okay...
I need to install any Sofware for the use of SQL. I'm just a begginer and started an online course. We have a account at work called Administrator and the only account has acces to SQL Managment studio 2014. Inside there are multiple databases linked to the external objects for stock contol purposes to collect data and view data, database was created by another company not us. Id like to download an SQL Software to run simple queries. But would need to know if it would affect any other databases or servers inside our network?.. just need to set it up for my local use.
Thanks
we want to deploy our Software on different editions of SQL Server. So we made a CoreDB Project, and for every edition (Express, Standard, Enterprise) seperate projects. Each references the CoreDB to reduce the amount of objects to define.
Now we want to deploy to Azure DB, but we can not reference the CoreDB from an AzureDB Project.
Any Ideas?
Thank you!
Assuming that you are referring to creating CoreDB and AzureDB as Database projects in SSDT -
Unfortunately SSDT will not allow you to create a Database Reference to another database with a different version. To relate to your earlier example, the following scenario will not be allowed in SSDT:
CoreDB's target platform is SQL Server 2014
AzureDB's target platform is Microsoft Azure SQL Database V12
Check a similar question posted here: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/af6005a6-5c4d-4c1c-bd8b-209d320ceef7/error-setting-up-db-reference-from-dacpac-versions-dont-match?forum=ssdt
If you've found a way of "reusing" the CoreDB code for different versions since you last posted this, please let me know.
Personally (and based on past experience), I'd use source control to create different branches reflecting the different versions. This allows independent release and code management. It does require more deployment management and synching up, to ensure that the relevant objects will get the same updates.
Julie
I have created a Database in SQL Server using MS SQL Management studio.
I'm looking for a simple GUI tool to easily search in the database or add new data to the database.
for example, if my database stores links for pictures - each picture has some tables like location, objects, animals, lighting etc.
I want to be able to search the database, so i can choose of a box list for each table instead of Querying through the SQL.
i understand this can be done with Sharepoint and MS Access, but i recon it's too complicated.
any thoughts and ideas?
thnx.
Try using EMS SQL Manager for SQL Server - it has free Lite version which ones limitations are acceptable.
Also you may try DevArt's dbForge Studio for SQL Server - this product's progress is very impressive. It's one of the best solutions for managing SQL Server.
I am working on a team that have a number of developers working with SQL Server, developing stored procedures, functions etc.
I would like a consistent layout between the SQL, same header with a copyright etc. SO I need a standard template for the SQL. I know in Visual Studio it is possible to share templates.
How can I generate such a template for SQL Server Management Studio that I can share between developers?
This is how I do it:
the physical location of my template is in(Win7 SQL Server Management Studio 2012):
C:\Users\ys\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates\Sql
I created my own folder in it (00_Mine)
Created a git repository
Asked other devs to pull from it.
In SQL Server Management Studio, press Ctrl-Alt-T or go to Menu, View, Template Explorer
It will list all the templates. However, from SSMS, there is no easy way to add templates to it by drag and drop, you can create new ones and put them into a folder, such as _WORK_.
The templates live physically in (for 2008 R2): C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\SqlWorkbenchProjectItems\Sql, so you can simply drop files and folders in there or push out to team members using group policy. The templates are sorted alphabetically, hence the suggestion for _WORK_ above. Note: A restart of SSMS is required to pick up Template Folder changes.
Here's an article: Using SQL Server Templates
Question to users of template functionality: do you think it will be helpful if you had a possibility to have placeholders for data like: Current database, Current User, Date/Time (something else ?), so, when you open the template these placeholders would be replaced by appropriate values. I develop an add-in and had this idea a time ago, but I do not know if someone really needs it.
I'm working on a project which relies on the presence of a number of tables, views and stored procedures. Until now I have built these all in SQL Server Management Studio.
Now I would like to continue to work on them inside of Visual Studio. This will provide the benefit of version control (along with a number of other benefits hopefully).
I have added a new project to my solution and started working on one of the views. When I tried to build the solution it failed as the new project didn't have a server/database associated: Error 1 SQL03006: View: [dbo].[vw_Test2] has an unresolved reference to object [EV870_ACCT_MASTER].
I was able to overcome this by
-creating a dbschema dump using vsdbcmd.exe
-adding the dbschema dump as a reference to my database project
Is this the correct approach?
Now i can see the schema (tables, views, sprocs etc) in the Schema view (I had to enable display of "external elements") and the error message has gone away. Note: I had to reference like: [$(SQLDatabase)].[dbo].[EV870_ACCT_MASTER]
Now I want to know how I can work with these objects that i've scripted. I don't know how to use the new tables, views, sprocs etc (I want to use LINQ). Do i have to run the scripts first? How then if they are "CREATE OBJECT" scripts, will they run in future (presumably they'd fail as the object already exists in the database). Will my project/solution know which objects need updating and update them?
Ultimately want to take it a lot further- my aim is that the solution will be portable and a the server/database will be configurables. Then my tables, views and stored procedures will be created or amended if they don't exist or are out of date. Is this possible?
When I then start working with the views etc using LINQ I want those server/database references to remain dynamic?
I know there are quite a few questions in there but i'm hoping someone will be able to point me in the right direction- there doesn't seem to be much useful documentation online (or that i've stumbled across so far).
Thanks
Lee
Where I work (and the last place I worked) we distribute the sql scripts to create the database along with the app. In sql a version number is stored and when the app is run it checks to see if its version is newer than the number stored in the database. If so then it knows it may need to run some new sql scripts in case there were any schema changes. When this happens, we just run through all the scripts because they are written in a way that running them multiple times won't hurt anything... this way we don't have to worry about tracking which scripts are the new ones. Just check the version number and that's it.
As far as working with this stuff in Visual Studio instead of Management studio, I'm not sure why anyone would want to do that. Depending on what you use for source control you may be able to get hooks for Management Studio, but even if not that doesn't stop you from keeping your sql scripts in source control. And I wouldn't switch from working with my sql files in management studio to visual studio for the benefit of having built in source control any day.