Updating dbml files
However, I've found the following techniques assist in getting a correct refresh: 1.Add a new parameter to the sproc, then do perform the above. This appears to be a more solid solution and the one I currently perform when the all of the above fail.The following code is an excerpt from the DBML file created from the Northwind sample database.You can generate the whole file by using SQLMetal with the /xml option.
I've yet to work out exactly how it decides when to grab a 'fresh' version of the sproc.However I have to admit it's the current method I use for creating a Data Access Layer (DAL), albeit one which ultimately calls Stored Procedures, using LINQ to SQL This leads me to a problem I've been having recently, where I drag a stored procedure on from the Server Explorer in Visual Studio onto the file, which is all very nice and easy, but when it comes to changing the stored procedure such that it returns a different set of datatypes, or it's input parameters change, it's not been so easy to get the dbml file to reflect this, or not at least in a way I expect it to.So my previous workaround was to create a new file, dragging the changed stored procedure to this file which generate the auto generated code correctly for the new version of the stored procedure, I'd then simply copy that code to a new file I'd call 'dbml Filename-extension.cs' and then everything was fine to work from that file. A bit fed up with this, I managed to work out a better way to handle this, in what would appear to be the way it was designed to be done, just my thinking was maybe a little different expecting it to work in another way, but now I've discovered it, it makes good sense. Delete the stored procedure from the design surface of the file 2. Click Refresh in Server Explorer on the list of Stored Procedures 4. Check the code file and you will have the updated C# code for the new version of the stored procedure I had a bigger list to start with and I've been removing steps, so it's possible without further testing that some more steps could be removed.So Microsoft decided to stop investing in Linq to SQL and put al its effort in Entity Framework.This means that although Linq to SQL is a nice ORM framework, it’s missing some useful features.