By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,669 Members | 1,540 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,669 IT Pros & Developers. It's quick & easy.

Linq to SQL - Bug?

P: n/a
Hi All,

I am using Linq to SQL dataclass for my website application.

This was working AOK, but then I deleted and recreated the dataclass
(Seemed the simpliest way of updating the class to reflect DB
structure changes).

Since then, I have to declare the connection differently:

DataClassesContext DB = new DataClassesContect(<4 Overloads, expecting
a connection string or object>);

Before, I did not need to pass a connection string or object, I just
did this:
DataClassesContext DB = new DataClassesContect();

This worked Ok, so I can only assume the connection was defined as
class level within the datacontext.

Question is, why did this change - I added the class the same way I
did originally, dragging tables onto the Linq to SQL surface designer
from an SQL connection in server expolorer.

If I do pass in a connection string I get 'object reference not set to
an instance of an object' when ever a query runs.

Any help/ideas much appreciated!

Thanks,
Simon.
Jul 3 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
As you said, there are some overload for the context. The one without any
argument uses the default connection (as you can see in the generated code)
which is maintained by the Data Connection you created in your Server
Explorer. You can use the overload specifying a string (connection string)
as argument, so you can easily switch from your testing data context
server/db to your production data context server/db, by changing that string
appropriately.

It may have be that you re-created the data class using another data
connection (even if it is only with some difference in options you used)?
Vanderghast, Access MVP
"TisMe" <si**********@googlemail.comwrote in message
news:26**********************************@k13g2000 hse.googlegroups.com...
Hi All,

I am using Linq to SQL dataclass for my website application.

This was working AOK, but then I deleted and recreated the dataclass
(Seemed the simpliest way of updating the class to reflect DB
structure changes).

Since then, I have to declare the connection differently:

DataClassesContext DB = new DataClassesContect(<4 Overloads, expecting
a connection string or object>);

Before, I did not need to pass a connection string or object, I just
did this:
DataClassesContext DB = new DataClassesContect();

This worked Ok, so I can only assume the connection was defined as
class level within the datacontext.

Question is, why did this change - I added the class the same way I
did originally, dragging tables onto the Linq to SQL surface designer
from an SQL connection in server expolorer.

If I do pass in a connection string I get 'object reference not set to
an instance of an object' when ever a query runs.

Any help/ideas much appreciated!

Thanks,
Simon.
Jul 3 '08 #2

P: n/a
It may have be that you re-created the data class using another data
connection (even if it is only with some difference in options you used)?
Michael, thanks for your reply - I think you are right here, this is
what caused it. Although I still dont follow why the first time round
resulted in the default connection is used, with no overloads on the
context, yes the 2nd time round resulted in the overloaded method.
i.e. What specifically, within the server mananger connection object,
causes this behavour to differ?
Jul 7 '08 #3

P: n/a
I am not sure, I don't know the mechanic involved behind that scene.

Vanderghast, Access MVP

"TisMe" <si**********@googlemail.comwrote in message
news:69**********************************@k30g2000 hse.googlegroups.com...
>It may have be that you re-created the data class using another data
connection (even if it is only with some difference in options you used)?

Michael, thanks for your reply - I think you are right here, this is
what caused it. Although I still dont follow why the first time round
resulted in the default connection is used, with no overloads on the
context, yes the 2nd time round resulted in the overloaded method.
i.e. What specifically, within the server mananger connection object,
causes this behavour to differ?

Jul 7 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.