Take the 2-minute tour ×

I have an asp.net application developed. It uses LINQ to SQL to access database, using the .dbml designer in Visual Studio 2008. We are installing the application on client, and they have decided to change the database name on their servers. Now, the application does not work because LINQ can't find the database information. This is not an issue with the connection strings, but with the files generated by the .dmbl designer. I suppose we have some options: 1. Change the development database name to match the client's name, regenerate de dbml, recompile, and send the application again to client. 2. Install VS2008 on client and make the necessary modifications there.

None of the options seem really good. This is not the end of the world, but it is a real pain. I hope there's a more reasonable solution! Any ideas?

After studying the problem a bit further with the help of your answers, I think the problem lies with the schema. To sum up, the database has a new name and a new schema. I suppose the sqlmetal.exe option is the best one right now. Anyways, if this is the case, I still think it's a real pain.

share|improve this question

4 Answers 4

up vote 4 down vote accepted

I would say it Is a connection string problem, see the generated class:

    public SomeDataContext() : 
.ConnectionStrings["someConnectionStringKey"].ConnectionString, mappingSource)

Please provide more info. Perhaps you mean an schema change, in which case I strongly suggest to have it the same on the dev environment.

Update 1: Perhaps the DatabaseAttribute on the generated class confused you.

Use the Name property on a DatabaseAttribute attribute to specify the name of a database when a name is not supplied by the connection

Source: http://msdn.microsoft.com/en-us/library/bb399355.aspx# (enpashis by me)

Just specify the database in the connection string, and you are good to go.

Update 2: If your generated class for some reason doesn't has the above code (and you aren't explicitly specifying one in the parameter), open it on the designer, open the properties, and make sure it is configured in the Connection property with Applications Settings set to truth.

share|improve this answer

There's an exe as part of VS2008 class SQLMetal.exe which does the important part of generating the DataContext.cs file. I think all you'd have to do is change the DBML file (it's a simple XML file), run SQLMetal (producing a .CS), and then run csc.exe (part of the .NET framework) to produce an Assembly (It'll be easier if you put the DataContext in an assembly by itself). This essentially boils down to option 2, but with far fewer files which need to be installed.

Update: Re-reading you question, I realize it's not the table names that changed, but the database name. This is a different problem (although the solution described above will work for that too).

When VS2008 generates the DataContext class from the .dbml file, it creates two constructors: One which taken no parameters, and once which takes one string (plus a couple more ctors, which we can ignore).

The zero parameter ctor uses the connection string you used when you created the dbml, which it then embeds in the resource file. This is an incredibly dumb design, and really should only be used for proof-of-concept code and demos.

All real production code should use the ctor which takes a string -- specifically, the connection string --- which you should read out of the app.config file.

This of course means the "correct" solution is option #1 -- rewrite the code at your office and re-deploy. It's a bother, but in the long run, it's for the best.

share|improve this answer
@james: that's actually wrong, linq2sql does supports using the connection string, see my answer –  eglasius Mar 10 '09 at 20:45
um.. what part is wrong? I said it can use a connection string. (2nd to last paragraph) –  James Curran Mar 10 '09 at 21:20
I'm reviewing the code and the class is instantiated using the constructor with the connection parameter. Anyways I'll keep studying the problem. Thanks for your answer! –  rgargente Mar 11 '09 at 8:17


I'm surprised that this would cause an issue. I've developed around 5 Add-on pieces using Linq to SQL. The only thing that I had to do to circumvent this was to do the following:

using (NamedDataContext ctx = new NamedDataContext("{insert connectionstring from config file/registry entry/etc. here}")) {

... code to be done against the database ...


and have not run into any issues yet at this point. I'm confused as to why your application doesn't have a configuration method to handle configuring your database connection, as that is usually the first thing most applications need built into them.

share|improve this answer
@richard, I did something similar but only because it was specifically needed to grab the connection string from a different place ... I used a static property in the partial class, so my code did MyDataContext.Default. It is quicker to just use linq support for this, see my answer. –  eglasius Mar 10 '09 at 20:52
Freddy: I saw that, but I must have read OP's message wrong... his schema changed completely... so no matter how he was doing it, it was going to break... such is life with development in general, outside of what anyone stated here. –  Richard B Mar 12 '09 at 5:26

Personally I would tell the client that changing the database name from what was developed will cost them $XX in new development costs and watch them change the name right back.

share|improve this answer

Your Answer


