I am trying to create a database project in Visual Studio 2012/2010 where I need the CDC (Change Data Capture) tables , because lot of my views are dependent on the CDC tables. I couldn't find any way to import the cdc schema/tables :(. Read in many blogs that importing cdc is not supported. Is there any work around. Please suggest
Generally you wouldn't really want the CDC tables to be created by a database project, you want them to be created using sys.sp_cdc_enable_table
If you allow the database project to create the tables in a normal manner then the CDC tables would end up existing but their Change Data Capture wouldn't actually be enabled.
Obviously you can script the calls to sys.sp_cdc_enable_table in either Pre or Post scripts, but as far as I can tell neither place is ideal.
If you put the sys.sp_cdc_enable_table calls in a Pre script changes are that not all the original tables exist (on a fresh deploy none of them will exist), or that these original tables will change shape as part of the main deploy that occurs after Pre is run.
If you put the sys.sp_cdc_enable_table calls in the Post script, you can't have Views that rely on the CDC tables existing deployed as part of the main database project deployment (not without errors or warnings in your DB project).
I would suggest not having too many views, functions or stored procs that rely on the existence of the CDC tables, but it sounds like it might be too late for that.
Side Note: Generally speaking you should be using the cdc.fn_cdc_get_all_changes_ and cdc.fn_cdc_get_net_changes_ functions rather than referencing the cdc tables directly, see Querying Change Data Capture data
However, that just moves the problem along one level to those functions not existing in your project.
Unfortunately, there doesn't seem to be a good way to have those extra views without scripting them at the same point that you script your calls to sys.sp_cdc_enable_table
(I'm honestly hoping someone else will come along with a better answer that actually solves the problem)
We came across the same issue recently in a DB project using TFS/VS for builds during the implementation stage.
As Scott correctly said, it's not a good idea to attempt to implement either cdc schema or any objects inside the project/solution, this has unfortunate consequences which you really do not want to experience!
For TFS/VS projects, you should implement a Pre-PostDeployment Script strategy, whereby CDC can be disabled during the PreDeploy process and then the instances are recreated during the PostDepolyment process.
In this way you can assured that the correct CDC instances are created uniformly.
When you consider the dependent views, again, the strategy is not difficult.
Create the view as you normally would in the project, but as a placeholder (e.g. a simple CREATE dbo.vMyView AS SELECT 1 FROM SomeTable). In the PostDeployment scripts, add a further script that executes AFTER the CDC instances have been created, with ALTER statements for those views (e.g. ALTER VIEW dbo.vMyView SELECT Col1 FROM cdc.MyCDC_CT). Remember, a view, once created, can exists even if the underlying table doesn't.
Related
We have two software projects that both communicate with a single database. Right now SQL updates are all done on the database and it's relying on developers to make sure to update both sets of projects independently to use the latest database model. Making these matters worse both projects are in separate solutions in separate source control repositories.
While I acknowledge this is a terrible situation to be in, I inherited this situation, and while my long term goal is to consolidate and share the (lots) of duplicated logic between them in one common project shared among both sets of application for various reasons it is not feasible to jump right into that right now due to critical deadlines coming up and the need to combine them iteratively and schedule it with other developers to not disrupt work too much.
Keeping that in mind, I really want to use SSDT to at least start bringing the database structure under source control and make it easier to manage, as there are quite a few database changes that I'm about to do.
The problem with SSDT in this scenario is that you can only import from database once. After that the option is greyed out and unavailable, which is apparently a design decision of SSDT, since it's explicitly listed in the MSDN documentation.
Is there any easy way to update my SSDT project without nuking the current project and recreating it each time someone makes a change to the database structure?
Firstly your right, it is a horrible situation so work on improving it in the long term!
There are two things you can do, firstly you could use SSMS "Generate Scripts" to export all the objects and then use the import in SSDT to import from the scripts - this isn't greyed out.
The second thing you can do is manually bring the changes in using the schema compare in SSDT, you can set the database as the source and project as the destination and choose what you drop, update and import.
Ed
its bit delay in answer. I am using VS2017 Database project in which I have achieved this task by comparing a local database with database project once the comparison is over you can update the database by update button
Step 1 right click on the database project and click on schema compare item.
Step 2 select target -> select database connection option
Step 3 change source and target
Review Screenshots for more detail
I am going with compare solution :
Choose schema compare and make your database as a source and database project as a target then compare and update
see the this answer
Make a new temp Database project (outside of TFS) and import all the objects.
Checkout the Database project (inside TFS) and copy and paste all the folders (excluding BIN, OBJ folders) from the new temp Database Project into the Database Project (in TFS) and check in. This was way you get the latest DB object into TFS without duplicating.
If you expect new files in the copy/paste operation, then the new files should be included in the DB Project.
Delete the temp Database project folder.
You will need to do the process whenever you want to update all DB Objects into TFS.
This is a workaround which worked for me for this file duplicating issue.
We are looking to introduce odac into our application but I am running into a number of issues and I can't seem to find any solutions that fix our issues.
We are using an oracle database and trying to use ODAC 12c Release 1 (12.1.0.1.0) with Oracle Developer Tools for Visual Studio.
In our model we would like to have multiple schemas so we can perform cross schema queries. The schemas which we select in the filter for the database connection appear when we are creating the model. However when we try to update our model from the database only the default schema is visible. Sometimes this can be fixed by opening the relevant part of the database in Server Explorer in Visual Studio but this doesn't always work. This fix never works after we add multiple connection strings for the same model (depending on the location of the user will depend on which database the user gets directed to).
The next issue we are having is that we can't the return types of stored procedures to be auto-generate. I have tried to retrieve the column information but it is never able to retrieve the metadata. I have seen a few suggestions of modifying the stored procedures then getting the column information and reverting the stored procedures but this is something we would like to avoid. Also the suggestions don't seem to work on oracle databases (but that could be me, I don't have much experience with databases).
The final issue (this is a minor issue) is that I cannot figure out how to get the generate code to omit underscores from the classes/methods generated. This isn't a huge issue it is purely to make it easier migrating the code we have.
I have a Visual Studio 2010 database project and I'd like to do a partial deployment, i.e. of specified objects. Is this possible? The only options I can see are to either do a full deployment or stop after generating the script.
For example, I'm changing many tables and stored procs but not everything is 100% finished and I'd like to push out a specific stored procedure to my test database, including its permissions, etc.
I read a little bit about SQL Server Data Tools, which apparently supports this, but I'm not clear on whether I'd have to migrate my database project to use that instead (would also need the ok from team lead), or if it's simply a plugin that would allow extra functionality.
Check out Schema Comparisons. They allow you to select the objects you want to deploy. They are available without SQL Server Data Tools.
A "partial deployment" is actually a little dangerous. Consider that you will have just built your database project, your entire database project, complete with the table changes, and it has built with no errors or warnings (right?). Now you want to deploy just your stored procedure, into a database that does not have the table changes.
Your stored procedure got no errors or warnings in the context of all the changes. Are you sure it will get no errors or warnings without those changes?
You should consider a source control solution to this problem. Save a copy of your stored procedure, revert to a version of the code that matches the database you'll be deploying to, then make your stored procedure changes to that. When you deploy, you will be checking to see if the stored procedure makes sense in the context of the database you'll be deploying into.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.
I'm currently investigating ASP.NET MVC 2 and LINQ to SQL. It all looks pretty cool. But I have a few application and development lifecycle issues.
Currently, I design the DB in SqlServer Management Studio.
Then I update my DBML files by deleting and re-importing modified tables.
Issues:
I can't find how to simply update the whole DBML schema.
My DBML then loses some of the changes I made such as renaming relation members or mapping of some int to an enum.
If I want a SQL script to deploy my DB (or to keep the schema under source control), I need to go use the 'Genererate Script' SSMS wizard which would be cool if a) it could remember my settings and b) it could be automated.
Should I work the other way around (start from my DBML and generate the DB)? Should I go for some other framework (NHibernate? Can I use some Linq flavor with it?)
Also, I read that LINQ2SQL is already obsolete in favor of Linq to Entities. Does it mean that the ultimate tool supposed to make my life so much better will again make me lose time in the long term?
Thanks for shedding some light.
If you are starting your DB Schema from scratch you could consider "Code-First Development with Entity Framework 4" as outlined by Scottgu.
I have been using this on a new project and am finding it extremely beneficial - especially for testing.
I started with simple POCO classes representing my data, then as the project progressed I would allow EF4 to generate the schema to a "real" DB using my "in-memory" example data ... now I am using a mixture of both in memory POCO (for development and TDD) and auto-generated DB Schema (auto-loaded with more "realistic" data) for demonstrations etc ... so far I am very happy.
There is a lot of opinion over LINQ2SQL and whether it's 'obsolete' or 'discontinued'. But it is still in the .NET framework and a good tool, so if it suit your needs then you should use it. Frankly the Entity Framework is still not perfect and if you don't need the extra flexibility that it affords then it is not worth the pain. If I had a small to midsize project then I would definitely use LINQ2SQL again (and over EF).
As for your question, yes you'll lose any names or different type mappings when you remove and re-add a table. The options that I'm aware of are
Only remove / re-add the table that has changed (not all tables)
Try altering the DBML tables in place, rather than remove / re-add. You can add and remove columns, change column names and data types, add relationships all on the DBML.
I like JcMalta's suggestion of creating objects as classes before rendering into the database, but if you find SQL Studio to be quick to develop with then it might simply be quickest to create tables there are drop them into your DBML. It's a touch annoying to have to change something in a database and the push the changes into your code but the code-gen tools are quite good and take away most of the pain.
You can try CodeSmith/PLINQO to auto-sync DB/code:
http://plinqo.com/
As a follow-up, just wanted to say that I eventually found and fell in love with Huagati DBML/EDMX Tools.
To be totally honest, I must say that the price has significantly increased since I purchased it. I believe it is still worth the money anyway.
And for people who are looking for the same kind of tool for MySQL (or other), DevArt is your friend.