Linq to SQL - Bug?

[TisMe]

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:

DataClassesCont ext DB = new DataClassesCont ect(<4 Overloads, expecting
a connection string or object>);

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

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.

[Michel Walsh]

Re: Linq to SQL - Bug?

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" <simonmharris@g ooglemail.comwr ote in message
news:262b0d27-ec3a-41d9-8c60-c63ac71ed65c@k1 3g2000hse.googl egroups.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:
>
DataClassesCont ext DB = new DataClassesCont ect(<4 Overloads, expecting
a connection string or object>);
>
Before, I did not need to pass a connection string or object, I just
did this:
DataClassesCont ext DB = new DataClassesCont ect();
>
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.

[TisMe]

Re: Linq to SQL - Bug?

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?

[Michel Walsh]

Re: Linq to SQL - Bug?

I am not sure, I don't know the mechanic involved behind that scene.

Vanderghast, Access MVP

"TisMe" <simonmharris@g ooglemail.comwr ote in message
news:6947b135-d196-4b76-b8fd-47a67cf97a79@k3 0g2000hse.googl egroups.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?