What is the best way to keep large projects organized with SSMS?
I want to do something like:
ProjectRoot
SchemaObjects
Tables
Constraints
Indexes
Keys
Functions
Views
Stored Procedures
Scripts
DataGeneration
And so on, but I cannot find a nice way to do this... Any suggestions?
I don't think there's anyway way to do this in SMSS, at least not in 2005.
Maybe a third party tool will give you this; there's a list of replacements for 2000 Enterprise Manager here; not the most current, but probably a good starting point.
Sadly there isn't. Maintain your object scripts out side of SSMS and simply edit them in SSMS.
IMHO this is one thing that is lacking big time in SSMS.
Related
This may be a pipe dream, but I'm hoping someone knows of a tool which can be configured to compare all or some (keys) of the data in two identical database and merge, perhaps based on relationships.
Specifically looking for one for SQL Server.
I'm not really asking for the best one, but if it exists it would be nice to hear how it is used.
Any other ideas for how to manage the work done or data added in dev and push it out to production without copying the entire database are welcome.
Thanks!
We use this and personally think it's excellent.
http://www.red-gate.com/products/sql-development/sql-data-compare/
There is also another product for the schema side.
http://www.red-gate.com/products/sql-development/sql-compare/
I don't know of a specific tools but you can implement in your process of publications the analysis and executions of delta files, containing the diffs from one verision to another. Magento, Wordpress are using something like this for example. They have something like this
//sql_update_001_002.sql
UPDATE some_table...
DELETE some entries
CREATE a_new_table...
// compere some keys or do other logic.
//etc
Then they have a script that analyses the current version and if needed it executes the corresponding sql.
Navicat allows to make data and structure synchronization between 2 databases (also located on different servers).
In terms of tools I agree with Chris - Redgate's toolset for both schema and data comparisons
If you are also thinking about your overall db dev process - then I have written a blog on the topic which might be of interest.
It also has some links to how others have tackled this subject.
http://michaelbaylon.wordpress.com/category/data-management/database-development/sql-script-management/
servers all sql server 2008, and win xp
i have the following task
create a huge database, DONE
distribute it to the 20 waiting servers!!
if there were two or three i would have taken the trouble of creating the db's on all of using sql server managemnt stdio
but i am guessing that there is an efficient way
please note,
only the copy of the database structure, the schema is needed not the values within the cells!
thank you
Or of course you should have been creating the scripts as you went along and putting them in Source control. Then you would have exactly which scripts you needed for this version of the software and be used to doing the same thing for later modifications. You would also script the data inserts for any lookup tables you need to build.
Not having that, you can script the entire database. or use a SQL compare tool. But I strongly urge you to start treating database code like all other code and scripting, storing it in source control and versioning it. Life is so much better when you do that.
What Gabriel McAdams has shown, or, Redgate SQL Compare does this very nicely also.
If you can spare the moolah, using a tool like Red Gate's SQL Packager is an option i have used in the past and it works well!
The tool can do a lot more as well and may not be worth the spend though if you do not need the other features!
In that case, Gabriels'option above is definitely the easiest one to go with!
I have a Databse "Product" in in sql 2008.I have another Databse "ORDER" in sql 2008.
Both exist in different servers.
Now the requirement is to Merge both databases, and test pointing the applications to this new DB.
Can anyone suggest the best way to accomplish this without losing the information?
I have 2 options.
1) Script the DB objects.(script both the DB and run this scripts inthe new DB)
2) Export DB
Which one in this is best or should i use any other methods to avoid errors.
I am new to SQL so please guide me with correct options.
Thanks
SNA
In my opinion the best way to achieve what you want is by just Exporting the database.
I think this is the best option because it's alot more safe then scripting the db's into a new one (a way to just get alot of frustration and errors).
Just try the exporting of your database first before trying to do anything with scripting (which obviously also takes alot more time). So try your fast solution first, and see if it will work.
(I see you are using sql-server 2008) Are you also using the management studio? If so, you can go into the tables in edit-mode and try to copy / paste rows into the new tables. I don't know how big your tables / DB's are, but this could also be an option.
Greetings,
Younes
As you say, two options are scripting or using the SQL server export/import wizard.
I've used both (for the same database as it happens)
A third option is to use Visual StudioTeam System 2008 Database Edition GDR.
In terms of a one time export and import then I'd recommend going with the wizard. This is very safe and also very straightforward. Particulary as you are new to SQL server, you want to take the approach that minimizes the risk.
The only downside to doing it this way is that it is perhaps a little less transparent than the other methods.
On the project where I merged databases I ended up using the scripting method but that was mainly because I had a project that was already using GDR to merge incremental database updates, so adding in a data merge script to that was a simple task - all changes needed to go through DBAs who unfortunately weren't very SQL literate (I know!) so keeping all the processes similar was a must.
I also took some of my learnings from scripting the data and applied them to setting up my reference data scripts, so the effort of scripting was not a one time cost.
Either way, the most important tip I can give is to back up the databases before doing any work on them.
I was just about to buy redgate.com's compare package when I came to realize it seems highly unlikely a task like this isn't something that can be performed from the Management Studio.
I have a development database and I have a live database.
I develop my application adding stored procedures, correcting small things in the data structure and maybe add some new tables.
Now I want the changes added to the live server. As it is unlikely I have kept 100% track of all of my changes I would of course like if it just new itself what I have changed.
Does anyone know what's best practice in Management Studio for this task? I mean it must be a task we all gets confronted with in larger projects.
If you do it with management studio it's all restricted to your own head. YOU will have to keep track of all the changes etc. I find that Redgates SQL Compare 8 and SQL Data Compare 7 does the trick. I recently moved the structure of a production database over to something totally different within minutes thanks to Redgate.
I have earlier tried to use Management Studio but it does not perform very well at complex tasks.
You really should be keeping your database schema in version control along with your source code.
What's wrong with it not being in the IDE? It has its own interface.
This tool save me hours a day. Not only because I dont HAVE to remember everything, but I then dont have to fix the production server if I missed something. I can work on multiple systems and push updates to each of them in a 10th of the time it would take me in the Management Studio.
This tool is by far the best 3rd party tool ive used for sql server. Its a godsend. A cheap one at that.
Just dont have the arrow pointing the wrong way ;-)
Okay I just bought Redgate :)
I have worked with it before so i can only agree that it is state of the art, I was just stunned to realize that Management Studio don't have anything that corresponds to this.
Thanks for the great answers!
Stackoverflow really is the pleace to ask these kinda things.
I'm looking for the single biggest reason you are glad that you've already made the jump from SQL2000 to SQL2005.
Recursion without creating temporary tables.
Native Exception support (Try/Catch instead of if #Error goto)
Because:
Microsoft would like to remind customers that support for SQL Server 2000 Service Pack 3a (SP3a) will end on July 10, 2007.
Native XML support is big for us here.
SSIS support. Blows DTS away and is quite handy. :)
SSRS - A really huge advantage for my organization is having the free reporting tools that come with SQL Server 2005. Reporting Services allows me to produce nice looking reports that have exactly the fields that our managers need in very little time. It has a built in tool so they can convert to excel, pdf, or several other formats. Lots of value here.
SSIS - Integration services in 2005 is very powerful for ETL (export, transform, load) functions. You can set up automated processes to run on a schedule.
SSAS - Analysis services looks promising. I have not made any data cubes yet because I want to organize an actual data warehouse. Once you have that, robust data mining algorithms are already built in.
Take a look at these three tools that are included with SQL Server 2005. If i had to pick one as the single biggest reason to move to 2005, it would be SSRS.
At this point, I would suggest looking at SQL Server 2008.
Pagination without (manually) creating temporary tables is a basic, but huge improvement.
However, if you are then going to drag & drop some GridViews in your ASP.NET app directly from the data table, you'd be paging in the app...
CLR integration
Row Versioning-Based Transaction Isolation
I think the single biggest reason is that SQL 2000 is not supported on Vista. I had to move to SQL 2005 because of that.
I don't know if it's just me, but Linq2SQL doesn't exactly work perfectly with SQL 2000. Ordinarily its supposed to automatically generate and populate child collections based on inferences from your schema's keys, foreign keys, RI, etc. Works fine in 2005 but i haven't had much luck in 2000.
Common Table Expressions have proven incredibly useful.
Exception handling... how did we ever manage on SQL 2000...?
PIVOT. That beautiful little statement has saved me more time then any other SQL Server 2005 enhancement.
YOU CAN'T EXPORT TABLES with a "right click" anymore. This is more of a problem than a good reason.
Dynamic Management Views
for Optimisation and to quickly find out the state of the server.