I have the situation where I'm working in a new database, built using a Visual Studio 2010 database project, which has a number of synonyms defined which point to our legacy database.
Our plan is to create views over these synonyms; the tables being referenced are horrible, so the views will mangle the data into a better format; after that we will use Entity Framework to provide an ORM for these views (the idea being that we can then swap the views for real tables as we migrate data).
Problem: I can script the synonyms in the database project with no problems. However, when I try to create a view which references these synonyms, I am confronted with an error similar to:
Error 1 SQL03006: View: [dbo].[Person] has an unresolved reference to object [dbo].[ma_contact].
...where [dbo].[Person] is the new view and [dbo].[ma_contact] is the synonym for the legacy table.
Workaround: Place all view creation scripts in Script.PostDeployment.sql, doing the if-exists-then-drop-then-create logic manually.
This is less than ideal, although it's livable-with for now. Anyone have any ideas as to how to do these views "properly"?
Have you tried adding a database reference to your original database? You'd have to extract its format into either a dacpac (for SSDT SQL Projects) or a DBSchema file (for DB Projects). Once you've done that, store it in some place the project can find it. We used a "Schemas" folder at the root of our DB Projects so all projects could reference it. In your project, right click the "References" folder and add a Database Reference. Search for your DBSchema/Dacpac file and use that, along with the name of the database. That should let your synonym resolve properly so you can reference it in your views.
Related
I've just made my database using Entity Framework Code First and everything is working great. However I want to see the schema of the entities; almost like generating an EDMX from the code first, but it doesn't have to do anything.
How do I do this I hear there is a nuget package for it, but i'm not finding it.
Thanks for the help!
The tool is called Entity Framework PowerTools CTP 1 and it is not NuGet package. It is standalone installer available on VS Code Gallery.
If you're using the Code First approach, you don't have .edmx schema/mapping files. The relationships between entities can be found within the POCO models themselves.
If you definitely want to use .edmx files, however, you can use the Database First approach. In that case, you would create your database manually and let the entity data model be automatically generated for you.
I am having serious frustration with DBML files not updating when I alter my stored procedures.
This is what happens. I alter my stored procedure. I then delete the stored procedure from the .DBML file and re-add it. It updates correctly in the .DBML file but the .designer.cs file does not get updated. The only workaround I have found is to delete the stored procedure, then delete the table that the stored procedure returns, add the table then add the stored procedure (all in the .DBML file). And this only sometimes does the trick.
Has anyone else had this problem? Surely there is a more suitable way to update DBML files in Visual Studio 2008?
Thanks in advance
There is no way DBML file gets updated as and when you change the SP.
I have a suggestion for you to get rid of it. This is what we followed in our projects.
Whenever you have update in your SP whether it is input or output parameters. Edit the dbml file as xml file (you can use open as xml in VS only) and save the dbml file. That will automatically updates the changes in designer.cs file as well. In this way you dont have to delete the SP from dbml and re-add it to get the updates. Though this is manual process but it really helps you a lot.
This way you can even modify the entity names (to comply with your entity naming conventions) for the output you are getting from SP as those default names are same as the SP name.
one more thing what i did was , opened server explorer from view. there it will list the db connections. there right click on that particular connection which points to your database and refresh. If you have added any new stored procedures or if you have updated any, it will automatically get updated.
1 keep in mind that SQL and VS is completely 2 separate services. it just connect together, doesn't mean it sync each other.
2 In my opinion DBML is kinda ms-sql only. i use to create DB Factory entirely operate base on interfaces and return data as DataTable ot DataSet. This code could use for all standard db.
Also in Entity Framework 6 this is a problem.
Delete the altered elements in the .edmx file and "Update Model from Database".
I'm building an asp application from the ground up using Linq-to-SQL as my ORM. I have a dbml file with a datacontext that includes all the tables of the database (15 for now). If I make changes to the database, by adding a table, adding fields or by changing the data type of a field for instance, how are these kinds of change handled when they occur?
Do I simply drag and drop the new table on the ORM mapper and voila?
Thanks.
Have a look at How to update Linq to SQL dbml file? [best practice] there you will find your answer.
I prefer to use SqlMetal (via a bat file) to fully regenerate the DB schema.
However, you'll find that SqlMetal generates for the entire database. To remove certain tables or relationships; and/or to rename certain tables or generated properties you could look at my blog on filtering items generated by SqlMetal using Powershell.
However, you could of course do it all via the visual studio designer, but that's manual and annoying to repeat for a small change. Or you could manually deal with DBML but that is nasty.
The Visual Studio IDE transfer the changes you do to your dbml file to your ORM classes automatically.
I love Linq but it can rapidly clutter up the namespace with automatically generated types. Usually these automatically generated types are often irritatingly close to other objects leading to many hours of fun and laughter.
In the designer I notice that I can specify the table names, however I can not for the life of me see how to set the row names.
For Example
TableName : User_Table
RowName : User_Row as opposed to "User_Tables"
I swear I've done this before but I can't seem to remember how.
You can do this by manually editing the dbml file in an xml editor. All names are stored separately in the dbml file, but not all are accessible from the designer.
Alternatively, there are third party tools that make handling names etc easier; one such tool is my VS add-in for L2S and EF. It adds naming rule support, mass-renaming, model <-> db schema sync etc to the existing L2S designer. You can download it from http://www.huagati.com/dbmltools/
I've been using this nifty LINQ to SQL tool for a data access layer in an asp.net project. I keep making changes to the underlying tables and in order for the data classes to recognize the change I have to delete and readd the table which has changed. Is there some shortcut to regenerating the data layer?
I've run into this same problem and using sqlmetal is definitely a good way to solve it. One approach is to create a batch file that executes your sqlmetal command and that way you can just run the batch anytime you need update your Linq to SQL classes, but what is even slicker solution is to use Visual Studio's Tools->External Tools function to create a command in Visual Studio that runs sqlmetal with your parameters. This works great and you can even drop the created command onto your toolbar for single-click rebuilding.
You could use sqlmetal which is the command line class generator for linq to sql classes.
LINQ to SQL version 1 does not support detecting database schema changes. The only way to have the generated classes modified is to regenerate them with either the designer or SQLMetal.
Keep in mind that there are not many differences between SQLMetal and the designer, the designer is a more 'pretty' UI for SQLMetal, and hides many of the command line switches.
I use the designer as I'm too lazy to constantly load up the command prompt.
In addition, make sure that you don't write any of your own code into the generated classes, otherwise you'll loose it on a regen. All generated classes are partial which means you can easily add your own extenders in a separate file.
For situations/models where SQLMetal don't quite cut it, e.g. due to different naming conventions in the database and your model, or some other customizations in your L2S model I have an add-in for Visual Studio that adds commands to synchronize your L2S designer with the underlying database [schema]. (plus a bunch of other L2S and EF related features)
You can read more about it, download it and get a 30-day trial license from http://www.huagati.com/dbmltools/
In the past where I've worked, we created a wrapper class to the DataContext that sqlmetal generated. Then we created a thin data layer that kept private the DataContext and all the classes generated by sqlmetal.
If any operations in the software needed information from the database, they had to go through this wrapper layer to get it. In other words, no LINQ to SQL could appear outside of this data layer.
That way, whenever we had to regenerate classes via sqlmetal, only portions of the data layer could break. Much easier to fix one layer where all the data access code is than to change sprinkles of LINQ to SQL throughout your logic or application domain.