i am using stored procedure and if i add/remove parameters (in the sproc) than when i come to see in dbml than i dont see any changes so what i am doing currently is remove the sproc and added back to dbml designer.
is this a normal behaviour of linqtosql?
in the future if i end-up modify the sproc for some reason do i need to end-up updating dbml also ?
There are a couple of ways of generating Linq To SQL classes from a database, neither of which offers round-trip coding or live update. If you change your database, including sprocs, then you'll need to regenerate your Linq to SQL classes.
Related
We are possibly looking at switching our tables, for views in EF 4.3.1.
We are using db first via the edmx file, so it generates our entities and dbcontext.
Has anyone got any tips for remapping our entities from tables to views?
Is this prone to disaster? We've had trouble with updating the edmx file in the past via the designer where the underlying changes weren't reflected deep somewhere within the code and we ended up with missing columns.
Or will views act very similar to tables in the EF world?
Designer handles views in completely different way - first of all all views used by EF through designer are read only unless you map stored procedures or custom SQL commands to insert, update and delete operation for each entity you want to modify.
Normally if you have updatable view you can simply modify SSDL part of EDMX and cheat it to pretend that the view is actually a table but this has two consequences:
You must modify EDMX directly as XML
You must not use Update from database any more because it always deletes whole SSDL part and creates a new one without your changes = you must maintain your EDMX manually or buy some extension for VS which will allow you updating only selected tables.
I am using Linq to Sql database model with MVC 2.0
when I try to update my model it not updating value, I try UpdataModel but it's also not working
If what you mean is updating Linq-to-SQL DataContext in .dbml Designer file, then you should just manually delete the modified tables and re-add them onto the designer surface.
Entity Framework's datacontext can be refreshed by choosing the "Update Model from database" from a context menu (but sometimes even EF requires readding items). For Linq-to-SQL this option, unfortunately, doesn't work.
If you mean to say that after dragging and dropping the new table to the dbml layout, you are not able to view the changes. You will have to build the project inorder to use the auto generated linq to sql classes. If this is not what you are looking for, can you elaborate on what kind of error you are getting ?
I am using LINQ2SQL in my current project. I have a quite a lot of tables ~30. When I create my DBML file I change some of the column names etc for readability.
Recently if I made a change to the table in the underlying Database I just deleted and re-added the table in the DBML file, but this is getting tedious. How can I mimic any changes to the database in the DBML file? (e.g. new column, drop column, new default constraint etc).
Out of the box, Linq-to-SQL has no update feature - amazing, but unfortunately true.
There's two tools I know of that get around this:
PLINQO is a set of CodeSmith code generation templates which handle DBML generation and offer lots of extra features (like generating one file per db entity) - including updates!
The Huagati tools offer updates and enforcing naming conventions for DBML and Entity Framework
Marc
I'm not expecting this to be the correct answer, but I thought I'd chime in anyway.
My approach has been to use the drag-n-drop feature for creating the initial DBML file. Then, any changes I make in my DB are also then made, by hand, in either the designer or in the DBML file (as XML) itself. (You can right-click on the DBML file, select Open With, and choose XML editor.) Sometimes it is much easier/faster to work with its XML instead of messing around in the designer.
I would only consider the deleting and re-adding, as you have been doing, if the changes were significant. For adding a new column, however, I'd suggest working directly with the dbml's XML, it's probably faster.
Good luck!
Welcome to the world of tedious! Unless I missed something, you're doing it the right way.
SubSonic looks like an interesting alternative, and boasts
It will also create your database on the fly if you want, altering the schema as you change your object.
As far as free solutions, there are a couple of blunt instruments that mostly move you away from using the O/R Designer: SQLMetal and Damien Guard's T4 templates.
There are multiple commercial solutions available that offer a lot more features.
The question you have to ask yourself is: Am I using the right ORM? LinqToSql has quite a few significant drawbacks, database change handling being only one of them.
Do not use the Visual Studio 2008 LinqToSql O/R Designer
The drawbacks of adopting Linq To Sql
Where I work it is a requirement for us to go through stored procedures as a mechanism to access our data through code. I am using LINQ2SQL to minimize this pain so that I can work with objects instead of ADO.NET directly. I have a situation Linq2SQL is consuming one of my stored procedures an generating code where the return type from the stored proc call is an int. The stored procedure actually returns a dataset. After doing a little research I have found that this is because the SQLClient library can not properly parse the sproc to generate the expected metadata that Linq2SQL uses to create the object graph. My question is how can sprocs (even complex ones) be structured so that you get an object graph out of linq2sql, or in other words what should you avoid having in your stored procedure that will create confusion for the SQLClient library to not understand how to generate the metadata that linq2sql consumes in order to create an object graph?
This is not actually a limitation of LINQ to SQL but rather of SQL Server which can not always tell a client what the return type would be without actually running it when it contains temporary tables, cursors or dynamic SQL.
As running it with invalid parameters could be potentially catastrophic it doesn't try.
You can either set it by hand using the designer or if it is absolutely okay to run the stored procedure with invalid data (i.e. it is purely passive) then you can add SET FMTOPT OFF to the start of the stored procedure.
DamienG works on the LinqToSql team at Microsoft and I have upvoted his answer as correct.
That said, he likely won't advise you away from LinqToSql and I think it's very important to consider that option.
Trying to guess the return type of a stored procedure is very difficult and LinqToSql does it as well as anyone (for SQL Server). That said, there are very compelling reasons not to use stored procedures:
Stored procedures are bad, m'kay?
If you must protect your tables from developers for "security reasons" (which I'm guessing is the situation you are in), it's best to do that with views instead of stored procedures.
If you are using views, you then have a lot better options in the ORM department than LinqToSql.
The main problem you are going to run into with LinqToSql in this regard is that what works fine for 5 stored procedures in a tiny database doesn't work fine for 50 or 500 stored procedures. You can use the O/R Designer to "override" the return type of a stored procedure, but you will have significant syncing issues when stored procedures or the tables, etc. they operate on change. Changes to stored procedures will not get reflected in the O/R Designer unless you remove the stored procedure from the O/R Designer, re-add it, and then reapply your custom override. If your project is like any normal project, the tables and stored procedures change often and this sync issue soon becomes a nightmare because it's completely manual and if you fail to do it correctly you will get very strange errors at runtime.
I would strongly advise against continuing down the path you are on.
I have a Client/Server application, where the Client and Server have some common tables (which are kept in synchronisation as part of the application).
We currently store these tables (i.e. FileDetails) in a Shared.dbml file. Until now, any stored proc that returns a result of set of FileDetails, has been placed in the Shared.dbml (even it is a Server-only) SP.
I released that the LINQ to SQL supports a Base Class property on the DBML, and I thought that perhaps I could have a Server.dbml, that extends my Shared.dbml. In theory this would give me a ServerDataContext with all the shared tables and SPs, as well as the server-specific elements. Normally in the SQL designer I would drag and drop the SP, over the FileDetails table to show this is what was returned, however as the class is in a different DBML this is not possible, and in the XML I don't think the ElementType IdRef="1" approach will work (as the ref needs to point to another file)
I found I can get around that problem by editing the XMLs return type manually:
<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
<Return Type="ISingleResult<DataTypes.FileDetails>" />
</Function>
My question is, does anyone have any experience with this kind of approach, and could point me to further resources? Are there any obvious drawbacks to it (other than than manual XML updates)
All feedback welcome
You could inherit from your datacontext. However in your new datacontext you wouldn't be able to use the linq designer you would have to code things out manually.
Is there any reason you don't want two datacontext?
Inheritance and LinqToSql don't play nice together in general. If you have a deep need for it you should look into another ORM like NHibernate.