How to debug problems with The Entity Data Model Designer (Entity Framework) - visual-studio-2010

I have inhereted some project which uses Entity Framework in a way which makes it hard to make there any changes. It uses QueryViews for almost all tables (cca 50 tables) and of course stored procedures. Now I have to change there quite a lot of things ... rename tables, add tables, change columns etc.
When I tried to use the "Update Model from database ..." wizard, than after the update (where I added/removed the tables and let refresh the others using the wizard) from the database the Entity Data Model Designer rendering stops working ... there is just blank window with the text "The Entity Data Model Designer is unable to display the file you requested."
So I tried different approaches (like manually editing the edmx file), but the problem remains. The editor shows only the "The Entity Data Model Designer is unable to display the file you requested."
The mapping using QueryViews makes it probably more complicated. It is well known that the designer can not work with the QueryViews properly (one can not edit them using the designer) and the Entity framework engine even does not recognize that the columns from CSDL are mapped using the QueryViews and complains on each and every column (which is mapped using QueryView) that "Error 11009: Property 'XXX' is not mapped." I see exactly 100 errors like this. Maybe somewhere after the 100th error, there is some hint (in the form of other errors) how to fix the issue with Designer, but I don't know how to see them. The 100 limit is most likely hardcoded in VS2010 (http://stackoverflow.com/questions/2880936/how-to-increase-error-limit-in-visual-studio).
Btw. the code (classes for entities etc.) is generated without problems.
So, the question is:Is there a way how to see some log or something, where would be noted why the Entity framework Data Model Designer is not able to render anything?
Or is there at least some way how to see the rest of the errors (besides the 100 errors)?
Or does anybody know the ideal way of dealing with updating schema in EF besides using the wizard?

Try to add new EDMX and right click >> open with >> XML editor, then you can see a complete set in an empty model definition in EDMX. So you can compare the two EDMX and check notice which part of the EDMX is missing.
Here is the error link

In the end I have just do all the changes manually by editing the xml. However, I used the model designer (the GUI integrated in VS for EF) for creating the whole CSDL layer. So my approach was to carefully choose tables in the correct order and add them one by one in the multiple iterations of the following steps:
Use the model designer to create the csdl layer for the chosen table including all relations with already existing table. This at least ensured that the designer was usable later on and it saves the manual writing of the CSDL objetcs.
Write the SSDL layer, which should reflect the DB table.
Write the mapping layer (in my case using the QueryViews).
Try to compile and resolve all compile errors.
Repeat for next table (or more tables if you find it easier).
I hope this will help somebody.

Related

SAP Business Objects 3.1 XI problems on regenerate structure

I have problems to refresh the structure of a table in my universe.
We have added some data to a reference table which is used in universe. After checking the new data in (Oracle 11g) database, found everything OK.
Then opened up designer in BO, imported the universe, looked up the associated table which only shows the existing items (not the new ones) - which seemed ok for me. I clicked on "View"/"Regenerate structure" but BO says that the structure does not need to be regenerated?
I have no idea what goes wrong and how I can add the new items to the table in my universe. Or do I have to update the content of a table differently?
It's possible that Designer isn't properly reading the database's data dictionary, and therefore not seeing the new column.
Data fields do not have to be present in the model in Designer in order for objects to reference them. So I would create a new universe object that references one of the new fields, and parse it. If it parses, then the field really is there and Designer just isn't seeing it. However if it doesn't work (i.e., you get an "invalid identifier"-type error), then the field is not there.
Joe's answer gave me the hint to check again why the new fields have not been there. And finally I found it. My "table" was a view which had to be actualized (SQL-select statement) and after that I could pick up the data into my universe and as shown in reports. Now everything is fine.

In VS2013 is there an easy way to update attributes in your model?

I'm using VS2013 in a MVC 5 app. Created EF6 model using the database first approach which yielded the model as expected. Subsequently I will make changes in the database objects (tables, views, stored procs). When I go into the model to update it, the visible model will get updated. Looking at the Model Browser, I have to manually clean up the artifacts that no longer exist. Am I missing something in my procedure?
When you right click and update the model from the database, it will typically add new pieces automatically, but in my experience it doesn't automatically remove pieces that are no longer there, so you'll need to watch for those and delete them manually.
On the plus side, if you had any special customizations around a field (e.g. enum types), and the field gets renamed, this gives you a chance to compare the two configurations and make sure they line up before you delete the old field from your model.

LLBLGenPro + VB6 project - accessing new columns added to a typedlist

I have a program made in Visual Basic 6 which access data from a database (made with Microsoft SQL server management studio express 2000 then migrated to 2005) and puts all data into an immense GridView.
The views, typedlists, queries, etc... all have to go through LLBLGenPro, which is used from what i learned to regenerate the entire code of our program in case we need to add anything. The project on LLBL contains entities, typedlists and typedviews. I'm not a pro of LLBLGenPro and i'm just starting to discover it
I have to add two columns to the Gridview with two specific tables columns containing the information i need. So i went onto the database to modify the view i needed to get the required data (which now gives me the two more desired rows), then i loaded the database again in LLBLGenPro and made sure to check my new fields in the typedList that contains them. I regenerated the program, and
started the visual basic project. My columns appear in all the files where they should be, with the right names (the typedlist and the views referring to it). The classes now find 23 column indexes instead of 21. All seems fine for now.
The typedList is then imported into the main class:
Private _typedList As New DBSqlTypedList.MyClassNameTypedListTypedList
All the items from the table in the DB are already loaded correctly by the code using filters and appear in the program without problem. The typedlist we need (imported as _typedList) fills the data in the gridview (GridBT) with the following lines:
If isOpenSoftware Then
With Me.gridBT
.AutoGenerateColumns = True
.AlternatingRowsDefaultCellStyle = Nothing
.DataSource = _typedList
Now here's the problem: _typedList does not see my two news rows at all and they don't appear in the grid at all.
Typing _typedList.item(0).xxxx for example gives me access to all the rows that were already there but none of the two i added appear in it.
Did I forget something in LLBLGenPro?
Don't hesitate to tell me if you think i didn't send enough code or information!

How many linq-to-SQL datacontexts per solution? I get the "menber is defined more than once" error

I have a relational database with about 15 tables that will be used in 4 different aspx pages (for now). Each aspx page uses some of the tables, but never all tables at once: for instance, one page might use 4 tables while another page might use 6 tables. I started doing a dbml file for the first aspx file with just the 4 tables needed. When I got to the second aspx file, I did another dbml file with just the 6 tables that were needed for this aspx file. 2 of the tables are in both datacontext dbml files and I get a "member is defined more than once" error.
After reading some online posts, my question about dbml files is this: when using linq-to-SQL, for an application, can we create multiple dbml files with the same tables or do we have to do just one dbml file for the whole application because a table can only be in one dbml file. If the latter is the case, do we need to simply include every database table in the dbml file and then always use the same datacontext throughout the project.
Thanks.
The dbml file shouldn't be the problem, but I guess you are using the designer, which automatically generates code - if you use two designers in the same namespace, the class names will collide. You've got three options then:
different namespaces
do the code generation yourself
use one datacontext with all tables.
Personally, I always go with 3., because linq-to-sql does support lazy loading, ie. there will be no resources spent if you don't query for any data.
dbml files are (after design time) irrelevant. What matters is the Designer.cs files they generate.
It sounds like you might be able to use 1 dbml file and then hand-code a CustomDataContext class to meet each page's needs.
The 'member is defined more than once' error occurs because you have two same-named classes in the one namespace.
Say one of your tables is called Product. When you drag that table onto the dbml (or rather when you save the dbml), the designer generates a lot of code in the default namespace, including a class called Product which contains properties for all the database columns. That's what you want but if you then go and create another dbml file in the same namespace, and drag Product onto the second dbml file, you'll end up with two Product classes in the same namespace - hence 'defined more than once'.
The solution is to change the Entity Namespace property on the dbml designer. Open the dbml, and without selecting any tables or relationships open the properties window. Under the Code Generation group there is a property called Entity Namespace. If you change that one to something else, you'll resolve the problem.
e.g. you might change it from MyProject to MyProject.Customers, or MyProject.Inventory.
The other option, as pointed out by Femaref, is to use a single datacontext for all pages. From what I read this is probably the more common pattern. I've only used multiple contexts when I have a large number of tables because the single dbml approach is unmanageable. But whatever works for you!

Problem refreshing tables in the LINQ to SQL designer

I have been using LINQ to SQL for a while, and there is one thing that has always bothered me. Whenever I modify the schema of a table, in order to refresh it in the designer, I have to delete it and then add it back. That's fine, but this means I have to actually find the table in the designer. I have about 100+ tables in my database, and every time I do this, it's like finding a needle in a haystack. Well, maybe it's not that bad, but seriously, it takes way longer than it should.
Is there another option for refreshing tables that I am unaware of?
Some people use SqlMetal to 'refresh/update' their Linq2Sql designer. The designer does not have support for refreshing the schema, when the DB changes. You have to manually drop the table and re-add it back in.
ADO Entity Framework i believe can refresh. I've not used it, but I think I saw this at a TechEd demo this year.
Helpful Info: Google's results for SqlMetal.
This is not possible using the VS linq to sql designer.
You can do this using LLBLGEN PRO, a third party tool, instead of the built-in linq to sql designer. It isn't free but it does do a ton of other stuff as well, which of course you may or may not need.
LLBLGEN PRO is actually a full set of ORM tools, but also includes an enhanced linq-to-sql designer with 'refresh model from SQL' functionality.
See here for description of the issue - http://weblogs.asp.net/fbouma/archive/2008/05/01/linq-to-sql-support-added-to-llblgen-pro.aspx
And here for the tool - http://www.llblgen.com/
I don't do any customization of the content on the designer so after table changes I just hit CTRL+A followed by DEL. Then shift-select all of my tables and slap them back onto the designer. I don't have 100s of tables yet so not sure if things slow down at some point but with 20+ tables it just takes a second.
I have written an add-in that can do that (in both directions; database -> DBML or DBML- -> SQL-DDL diff script).
Unlike SQLMetal (or EF's "update model from database") mentioned in another reply, the add-in does a true sync/refresh; applying changes corresponding only to the differences between the model and the underlying db.
That means any customizations (renamed properties/navigation properties etc) that you have made in other areas of your model will not be removed/overwritten unless they are in conflict with the underlying db schema. (in which case you can still preserve them by adding them to the add-in's "exclusion list")
You can download it and get a free 30-day trial license from http://www.huagati.com/dbmltools/
I have a similar comment, thought it might fit in here for anybody out there Googling a solution to this issue...
When I change the columns that are returned by a stored procedure, deleting the procedure from the designer and re-adding it does not work. The custom return type entity that the designer generates does not reflect the changes to the SP.
I've tried disconnecting the DB in the server explorer, even deleting and re-adding the connection.
The only solution I've found is this:
1. Delete the SP from the designer.
2. Save the dbml file (or the whole solution, whatever)
3. Completely close Visual Studio.
4. Re-open Visual Studio and your solution.
5. Re-add the stored procedure to the designer.
I think that qualifies as a blue ribbon pain in the rump.
Anybody got a simpler solution?
PS- To those of you with 100+ tables: Go get a real (real == mature) ORM tool. I personally vote for NetTiers. It rocks. Used it for years with no (or at least very few) complaints. You'll probably have to buy CodeSmith to use it effectively, but it's worth it. The templates are open source. And there are templates for nHibernate as well. But I've found that I don't really dig on Java ports. If I'm gonna code on MS platforms I want code that was "born" there...
...editorial complete. :P
I have had simliar issues with the designer - the best thing I can suggest is creating multiple contexts for different areas of your data access - I broke mine down to as few a related tables as I could get away with for each functional area. You can re-use tables across contexts so it isn't a big deal.
There's a template for VS 2008 that replaces the designer, it should ease refreshing your LINQtoSQL classes: http://damieng.com/blog/2008/09/14/linq-to-sql-template-for-visual-studio-2008
There are a couple of other options:
Edit the .dbml file that the designer uses to draw the tables and generate the code. I've used this approach when the changes are small (adding a couple of columns, creating a simple table)
Use sqlmetal to create the required xml for the changed tables and move the declarations by hand to the .dbml file. This one is better for when the changes are either more complex or larger.
I personally detest using the designer, and I've had various issues with it whenever I've dared to use it.
I mostly use LINQ for very simple CRUD (no linked entities or anything), and if that's the case with you, it might be worth straying from the designer crutch. Especially since defining LINQ-to-SQL entities is as easy as this:
[Table("dbo.my_table")]
public class MyTable
{
[Column("id", AutoSync = AutoSync.OnInsert, IsDbGenerated = true, IsPrimaryKey = true)]
public Int32 Id { get; set; }
[Column("name", DbType="NVarChar(50) NOT NULL")]
public String Name { get; set; }
}
This way, all your entities have their own files, which makes finding them much easier, though you'll still have to add/update the properties manually.
Of course, if you'd refactor 100+ tables, that might not be an option ;)

Resources