I have a database project in Visual Studio 2012 that requires access to a database not of my design through a linked server.
My initial approach was to script out the access to the database in 4-parts [server].[database].[schema].[table]. This approach throws SQL71562a and SQL71501 warnings/errors.
Through research I note that what I need to do is to create a database reference. My question would revolve around that process.
I thought the right thing to do would be to generate a DACPAC from the other vendor's database as it exists on the server - but I am unable to generate the DACPAC as it fails in SSMS (I think due to encryption).
My next idea would be to create a project that has the schema that I need from that database defined and then reference that (I haven't tried this yet as at first guess it is probably the wrong way).
Any help on this would be appreciated. Thanks in advance.
SSMS is very pedantic when it comes to extract DACPAC files.
You can however, use the SqlPackage utility for that:
SqlPackage /Action:Extract /SourceServerName:YourServerNameHere /SourceDatabaseName:YourDatabaseNameHere /TargetFile:YourDatabaseNameHere.dacpac
I had an issue just like that, in which this solved it, and documented it in:
http://tangodude.wordpress.com/2014/02/05/referencing-the-sql-server-data-collectors-management-data-warehouse-in-your-ssdt-database-project/
Creating a dummy/stub project does work though, but using a DACPAC file reference is much much simpler.
Related
I'm using microsoft SQL Server Data Tools (SSDT), in my projects to try to keep everything in order.
I was wondering if anyone know how to store the Database Diagram into SSDT Project, in order to don't lose any work and keep this model updated with my team?
I tryed to compare it using schema, but it didn't exists.
I also couldn't find any Database Diagram in Visual studio 2013.
Am I wrong to try to use this model type? Are there better ways to do it?
Also, Is it possible to create Jobs throught SSDT?
Thank you very much,
The database diagrams are stored in internal tables so you could add their definitions and include the data in a post deploy script but you would end up deploying to all your environments which is unusual (I don't know your circumstance so I won't say wrong!).
Unless you particularly needed the diagrams in ssms I would look to something else, redgate have a database diagramming tool, I prefer to keep a copy of Visio 2010 pro to generate them, the vsd files can then be added to the project and shared between the team.
I assume it is to help document your databases but If you wanted the editing and designer support from diagrams you get that other ways with ssdt.
Re: jobs, there is no native object but you can create them in pre/post deploy scripts.
We have a third-party SQL Server 2008 database that we have extended with our own tables, sprocs, etc. We would like to use a Visual Studio Database Project to manage our extension objects, but NOT the objects that are part of the third-party database.
If I create a project with only our objects in it, when I go to deploy they error out because VS thinks that the tables they are referencing (which are part of the original database) do not exist (because they are not part of the project).
I tried to create a DACPAC for the original database and just reference that, but there are new kinds of objects there, it looks like, which can't be pushed into it. I also have tried to just do a full schema compare and add all the third-party db objects into my project, but there are so many objects it appears to bomb VS. I will try that again today using a local database to see if perhaps there was a network issue contributing to that problem.
I'm not opposed to turning off those kinds of errors, if that is possible. I'd appreciate any suggestions.
So the answer was the DACPAC. I had tried with two different databases, to use the tool that is in the context menu for databases in SSMS, where you Extract a data-tier application, and both those databases failed. Following another post on S.O. I discovered this command-line tool, SqlPackage, that ships with SQL Server 2008. Here is a link that explains how to utilize it. Anyway I ran it against each of those databases and it didn't even hiccup. Nailed them both.
For me the application was located at: C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin
After you create the DACPAC files, copy them somewhere in your project, then do "Add Database Reference" either from the project menu or context-menu for the References node in the Solution Explorer. Add the reference, and remove the variable name it gives you. Select "Same Database" in the drop-down and you will see at the bottom what a sample query will look like. Hit OK and it sets it all up for you. All the referential errors disappear. Problem solved.
I have a huge database in production environment which I need to take a copy off, but the problem is that the data is over 100Gb's and downloading a backup off it is out of the question. I need to get a "skeleton" image of the database. What I mean by "skeleton" is, I need to get the database outline so that I can recreate the database locally by running SQL scripts.
Is there a quick and easy way to retrieve the SQL for recreating the database structure and tables?
Or will I have to write something in order to do this programmatically?
If you are using MS SQL Server then it's very easy to get your "skeleton". In the Object Explorer Right Click on the database node and then "Script Database as" and then "Create to". If the Database is in Oracle or something else sure there is a way also.
Managed to find this from Google.
I remember that if you can connect to the db from visual studio, visual studio have a publish tool, which can generate the script for you....
Hope this helps
Use the DDL Generate Scripts within SSMS :)
I need to get the database outline so that I can recreate the database locally by running SQL scripts.
Ask the guys who developed this application/database to provide you with the SQL scripts they used to create (and upgrade) the database. Hint: All these scripts should be in the project's source control repository, along with the rest of your source code. Yes, that's right, the SQL/DDL scripts are source code, too.
If the SQL/DDL scripts are not under source control, be very afraid, and run away from this project as fast as possible.
I'd like to have all DB DDL code under CVS.
We are using Subversion for our .NET code but all database code remains still unversioned.
All we know is how important DB logic can be. I've googled but I've found only few (expensive tools). I believe there exists other (cheaper) solution(s).
What approach do you advise to follow? What tools are most appropriate?
SQL Server 2005, VS 2008 TS, TSVN
UPDATE
Our coding scenario is that developers cannot access to PROD DB directly. It is changed only by scripts (so this is not a problem)
I'm mostly interested in the DEV environment where all of developers have full access.
So it happens that a developer overwrite USP previously changed by another.
I'd like to have the possibility to restore lost version / compare USPs revisions etc.
UPDATE-2
To create deployment script we are using Red-Gate SQL Compare.
Works perfectly - so deployment scripts are not a case.
If you haven't already read it, Martin Fowler's article Evolutionary Database Design is a great place to start.
The article is hard to summarize, but it describes how his team dealt with database versioning in a rapidly changing development process. They created their own tools to facilitate things: scripts to bring users up to the current master, to copy any version of the schema so users could debug one another's working copies, etc..
For a solid low-tech solution, I've found it helpful to keep two kinds of DDL scripts in source control:
A master version that can create the database objects from scratch.
'Version upgrade' scripts for each development iteration.
They're redundant to a degree, but extremely useful (particularly when it comes to deployment).
If you haven't already looked at the Visual Studio Database Edition GDR (a.k.a. "Data Dude"), you should definitely download it and try it out:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en
Among other things, the GDR will facilitate team development by making it easy for each developer to maintain their own local copy of a database, version scripts, create deployment scripts to move a database schema to a new version, and even support database rollback.
It's free if you are using team system developer edition. Check it out.
If you are using Visual Studio Team Suite or Visual Studio Developer Edition, you are entitled to a copy of Visual Studio Database Professional. This is designed to do exactly what you describe, and much more. We use it to manage our database schema (code).
Randy
We use Subversion for all our database code as well. Since nothing is allowed to go to Prod unless it is in a script, there seems to be no porblem with getting people to put all the scripts into subversion. We tend to write alter table scripts to change tables with existing data and then recreate the whole table structure in case we need to create a new database from scratch (we often have the same database structure on multiple servers as some of our clients are very large and do not want their data accidentally available to the competition and so pay for separate servers and therefore may need to create the whole database again with no data.) For objects that don't directly store data we drop the orginal object and recreate it with a create statement. Each project has it's own home inthe repository and each database does too, so the script may be in more than one place to facilitate deployment.
But the real key is that no one can load to Prod without a script. We don't give our devs direct rights to prod, so they have no problem doing things in scripts as opposed to using SSMS.
I wrote SMOscript which generates a CREATE script for each object in a database.
Use this tool to generate into a directory covered by CVS, and update your repository.
Finally I found this tool and approach extremely useful and very easy to introduce
(at least at the beginning - where no versioning solution on the place):
http://www.codeproject.com/KB/database/SQLScripter.aspx
You can run it out of the box.
For final solution I'd incline to GDR.
This also sounds interesting:
Freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
Commercial:
http://www.nobhillsoft.com/Randolph.aspx
You should use Management Studio (SSMS) and place the .sql under source control, possibly separate schema objects under folders.
Hope this helps
See if Wizardby fits your needs.
So recently on a project I'm working on, we've been struggling to keep a solution's code base and the associated database schema in synch (Database = SQL Server 2008).
Database changes occur fairly regularly (adding columns, constraints, relationships, etc) and as a result it's not uncommon for people to do a 'Get Latest' from source control and
find that they also need to rebuild the database as well (and sometimes they forget to do the latter).
We're not using VSTS: Database Edition (DataDude) but the standard Visual Studio database project with a script (batch file) which tears down and recreates the database from T-SQL scripts. The solution is a .Net & ASP.net solution with LINQ to SQL underlying as the ORM.
Anyone have ideas on an approach to take (automated or not) which would keep everyone up to date with the latest database schema?
Continuous integration with MSBuild is an option, but only helps pick up any breaking changes committed, it doesn't really help in the scenario I highlighted above.
We are using Team Foundation Server, if that helps..
We try to work forward from the creation scripts.
i.e a change to the database is not authorised unless the script has been tested and checked into source control.
But this assumes that the database team is integrated with your app team which is usually not the case in a large project...
(I was tempted to answer this "with great difficulty")
EDIT: Tools won't help you if your process isn't right.
Ok although its not the entire solution, you should include an assertion in the Application code that links up to the database to assert the correct schema is being used, that way at least it becomes obvious, and you avoid silent bugs and people complaining that stuff went crazy all of the sudden.
As for the schema version, you could use some database specific functionality if available, but i personally prefer to declare a schema version table and keep the version number in there, that way its portable and can be checked with a simple select statement
have a look at DB Ghost - you can create a dbp using the scripter in seconds and then manage all your database code with the change manager. www.dbghost.com
This is exactly what DB Ghost was designed to handle.
We basically do things the way you are, with the generation script checked into source control as well. I'm the designated database master so all changes to the script itself are done through me. People send me scripts of the changes they have made, I update my master copy of the schema, run a generate scripts (SSMS) to produce the new DB script, and then check it in. I keep my copy of the code current with any changes that are being made elsewhere. We're a small shop so this works pretty well for us. I realize that it probably doesn't scale.
If you are not using Visual Studio Database Professional Edition, then you will need another tool that can break the database down into its elemental pieces so that they are managable and changeable in an easier manner.
I'd recommend seriously considering Redgate's SQL tools if you want to maintain sanity over all your database changes and updates.
SQL Packager
SQL Multi Script
SQL Refactor
Use a tool like RedGate SQL Compare to generate the change schema between any given version of the database. You can then check that file into source code control
Have a look at this question: dynamic patching of databases. I think it's similar enough to your problem to be helpful.
My solution to this problem is simple. Define everything as XML, and make sure that both the database, the ORM and the UI are generated from this XML, no exceptions. That way, you can use code generation tools to quickly regenerate the database creation script, which will alter your schema while (hopefully) preserving some data. It takes some effort to do, but the net result is well worth it.