Creating database connection in main thread

G

Guest

Hi All,

when running this program

using System;
using System.Data;
using System.Data.OleDb;
using System.Data.SqlClient;
using System.Threading;

namespace TestDataAdapter
{
class Class1
{
private static OleDbConnection _connection;

[STAThread]
static void Main(string[] args)
{
_connection = createConnection();
Thread dataThread = new Thread(new ThreadStart(dataTester));
dataThread.Start();
Console.ReadLine();
}

private static OleDbConnection createConnection()
{
string connectionString = "Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security Info=False;Initial
Catalog=Northwind;Data Source=127.0.0.1;Use Procedure for Prepare=1;Auto
Translate=True;Packet Size=4096;Use
Encryption for Data=False;Tag with column collation when possible=False";
OleDbConnection conn = null;
try
{
conn = new OleDbConnection(connectionString);
conn.Open();
Console.WriteLine("Connection opened successfully");
}
catch(Exception)
{
Console.WriteLine("Connection could not be opened");
}
return conn;
}

private static void dataTester()
{
Thread.Sleep(1000);
DataSet ds = new DataSet();
//_connection = createConnection();

string sql = "select LastName from Employees";
OleDbCommand cmd = new OleDbCommand(sql, _connection);
OleDbDataAdapter adapter = new OleDbDataAdapter(cmd);
adapter.Fill(ds);
cmd = null;
Console.WriteLine("DataSet filled");
}
}
}

with a SQL Server the dataThread does not finish the call to apdater.Fill
until the main thread is finished. If I let the dataThread create the
connection or if I use SqlConnection instead this is not a problem.
An alternative approach is to let the main thread start a new thread doing
exactly the same as the main thread does in this example. This also solves
the problem. Can anyone explain this to me? Is this a bug?
 
M

Miha Markic [MVP C#]

Hi Morten,

Ouch, you shouldn't doing this as it is not thread safe!
Instead, let the thread create its own connection - the connection pool will
take care of reusing the spare connections.
 
G

Guest

Hi Miha,

Thanks for the response but there are still some things I don't understand.

if i look in the documentation for a OleDbConnection it says: "Any public
static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."

In the example I only use the connection in the second thread so i don't see
this could be a problem even if it is not thread safe. As I said earlier it
works fine with an SQLConnection. Shouldn't this connection type suffer the
same problem if it was a question of thread safety? Also, creating a new
"main thread" apparently removes the problem so i'm not convinced this is
caused by lack of thread safety.
I would very much like to hear if you are able to explain the behavior I
have observed, even if the only solution is to let the thread create its own
connection.

Miha Markic said:
Hi Morten,

Ouch, you shouldn't doing this as it is not thread safe!
Instead, let the thread create its own connection - the connection pool will
take care of reusing the spare connections.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Morten Nielsen said:
Hi All,

when running this program

using System;
using System.Data;
using System.Data.OleDb;
using System.Data.SqlClient;
using System.Threading;

namespace TestDataAdapter
{
class Class1
{
private static OleDbConnection _connection;

[STAThread]
static void Main(string[] args)
{
_connection = createConnection();
Thread dataThread = new Thread(new ThreadStart(dataTester));
dataThread.Start();
Console.ReadLine();
}

private static OleDbConnection createConnection()
{
string connectionString = "Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security Info=False;Initial
Catalog=Northwind;Data Source=127.0.0.1;Use Procedure for Prepare=1;Auto
Translate=True;Packet Size=4096;Use
Encryption for Data=False;Tag with column collation when possible=False";
OleDbConnection conn = null;
try
{
conn = new OleDbConnection(connectionString);
conn.Open();
Console.WriteLine("Connection opened successfully");
}
catch(Exception)
{
Console.WriteLine("Connection could not be opened");
}
return conn;
}

private static void dataTester()
{
Thread.Sleep(1000);
DataSet ds = new DataSet();
//_connection = createConnection();

string sql = "select LastName from Employees";
OleDbCommand cmd = new OleDbCommand(sql, _connection);
OleDbDataAdapter adapter = new OleDbDataAdapter(cmd);
adapter.Fill(ds);
cmd = null;
Console.WriteLine("DataSet filled");
}
}
}

with a SQL Server the dataThread does not finish the call to apdater.Fill
until the main thread is finished. If I let the dataThread create the
connection or if I use SqlConnection instead this is not a problem.
An alternative approach is to let the main thread start a new thread doing
exactly the same as the main thread does in this example. This also solves
the problem. Can anyone explain this to me? Is this a bug?
 
M

Miha Markic [MVP C#]

Hi Morten,

It could be not related to thread safety, yes, (is the code you are showing
all the code?) however, you really shouldn't use a connection created in
another thread.
 
G

Guest

The shown code is a constructed example which only serve the purpose to
illustrate the problem.

Miha Markic said:
Hi Morten,

It could be not related to thread safety, yes, (is the code you are showing
all the code?) however, you really shouldn't use a connection created in
another thread.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Morten Nielsen said:
Hi Miha,

Thanks for the response but there are still some things I don't
understand.

if i look in the documentation for a OleDbConnection it says: "Any public
static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."

In the example I only use the connection in the second thread so i don't
see
this could be a problem even if it is not thread safe. As I said earlier
it
works fine with an SQLConnection. Shouldn't this connection type suffer
the
same problem if it was a question of thread safety? Also, creating a new
"main thread" apparently removes the problem so i'm not convinced this is
caused by lack of thread safety.
I would very much like to hear if you are able to explain the behavior I
have observed, even if the only solution is to let the thread create its
own
connection.
 
A

Angel Saenz-Badillos[MS]

Morten,
If I understand your concern correctly you are not running into an exception
right? the only problem you have is that DataTester does not run until the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Morten Nielsen said:
The shown code is a constructed example which only serve the purpose to
illustrate the problem.

Miha Markic said:
Hi Morten,

It could be not related to thread safety, yes, (is the code you are showing
all the code?) however, you really shouldn't use a connection created in
another thread.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

Hi Miha,

Thanks for the response but there are still some things I don't
understand.

if i look in the documentation for a OleDbConnection it says: "Any public
static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe."

In the example I only use the connection in the second thread so i don't
see
this could be a problem even if it is not thread safe. As I said earlier
it
works fine with an SQLConnection. Shouldn't this connection type suffer
the
same problem if it was a question of thread safety? Also, creating a new
"main thread" apparently removes the problem so i'm not convinced this is
caused by lack of thread safety.
I would very much like to hear if you are able to explain the behavior I
have observed, even if the only solution is to let the thread create its
own
connection.
 
G

Guest

Hi,
It is correct that I'm not running into an exception, but I don't actually
use _connection in the main thread. I only instatiate the OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated in
the main thread. If it is a lock like you suggest I would expect to see the
same behavior if the connection was instatiated in any other thread than the
one using it.

I originally posted this question on the OleDb newsgroup but there are no
answers yet, so I would appreciate any help I could get here.
 
A

Angel Saenz-Badillos[MS]

You are right, it wouldnt make sense. I really can't think of anything that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Morten Nielsen said:
Hi,
It is correct that I'm not running into an exception, but I don't actually
use _connection in the main thread. I only instatiate the OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated in
the main thread. If it is a lock like you suggest I would expect to see the
same behavior if the connection was instatiated in any other thread than the
one using it.

I originally posted this question on the OleDb newsgroup but there are no
answers yet, so I would appreciate any help I could get here.


Angel Saenz-Badillos said:
Morten,
If I understand your concern correctly you are not running into an exception
right? the only problem you have is that DataTester does not run until the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
A

Angel Saenz-Badillos[MS]

Morten,
It looks like this issue has already been fixed for v1.1 in Service pack 1
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055

let me know if this fixes your issue.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Angel Saenz-Badillos said:
You are right, it wouldnt make sense. I really can't think of anything that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Hi,
It is correct that I'm not running into an exception, but I don't actually
use _connection in the main thread. I only instatiate the OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated in
the main thread. If it is a lock like you suggest I would expect to see the
same behavior if the connection was instatiated in any other thread than the
one using it.

I originally posted this question on the OleDb newsgroup but there are no
answers yet, so I would appreciate any help I could get here.


Angel Saenz-Badillos said:
Morten,
If I understand your concern correctly you are not running into an exception
right? the only problem you have is that DataTester does not run until the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
G

Guest

Hi Angel,

It seems that the code I posted works when using v1.1 Service Pack 1, but if
I add a _connection.Close() after filling the dataset the thread just hangs
here instead, and only finishes when the main thread no longer waits for the
Readline. Could you please refer me to the report number adressing this
problem?

The _connection.Close() is not an actual problem I have, I just found out by
coincidence, but I still would like to get an explanation.

I won't be able to test service pack 1 in the actual code where I first
encountered this problem right now, but I will let you know when I have
tested it.


Angel Saenz-Badillos said:
Morten,
It looks like this issue has already been fixed for v1.1 in Service pack 1
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055

let me know if this fixes your issue.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Angel Saenz-Badillos said:
You are right, it wouldnt make sense. I really can't think of anything that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Hi,
It is correct that I'm not running into an exception, but I don't actually
use _connection in the main thread. I only instatiate the OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated in
the main thread. If it is a lock like you suggest I would expect to see the
same behavior if the connection was instatiated in any other thread than the
one using it.

I originally posted this question on the OleDb newsgroup but there are no
answers yet, so I would appreciate any help I could get here.


:

Morten,
If I understand your concern correctly you are not running into an exception
right? the only problem you have is that DataTester does not run until the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
A

Angel Saenz-Badillos[MS]

Morten,
I wish I knew what the report number for this was, the process for this was
something along the lines of
Me> Does anybody know why this code is behaving this way?
Response> This works fine for me in SP1, can you try 1proc?
Me> Verifies it works with SP1 in 1proc 2proc and 4proc machine and respond
to newsgroup thread.

As you can probably gather I really have no idea what is going on. I will
try to repro this with a close after fill, if I can still get it to repro in
v1.1 sp1 I will do the same process again. I hope that this also repros in
the whidbey beta 1 since the process is much easier for current products
when there is a possible workaround for the bug.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Morten Nielsen said:
Hi Angel,

It seems that the code I posted works when using v1.1 Service Pack 1, but if
I add a _connection.Close() after filling the dataset the thread just hangs
here instead, and only finishes when the main thread no longer waits for the
Readline. Could you please refer me to the report number adressing this
problem?

The _connection.Close() is not an actual problem I have, I just found out by
coincidence, but I still would like to get an explanation.

I won't be able to test service pack 1 in the actual code where I first
encountered this problem right now, but I will let you know when I have
tested it.


Angel Saenz-Badillos said:
Morten,
It looks like this issue has already been fixed for v1.1 in Service pack 1
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055

let me know if this fixes your issue.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




You are right, it wouldnt make sense. I really can't think of anything that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Hi,
It is correct that I'm not running into an exception, but I don't actually
use _connection in the main thread. I only instatiate the OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is
instatiated
in
the main thread. If it is a lock like you suggest I would expect to see
the
same behavior if the connection was instatiated in any other thread than
the
one using it.

I originally posted this question on the OleDb newsgroup but there
are
no
answers yet, so I would appreciate any help I could get here.


:

Morten,
If I understand your concern correctly you are not running into an
exception
right? the only problem you have is that DataTester does not run until
the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they
are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
G

Guest

Hi Angel,

I have now tested the SP1 with my production code and the problems we have
found here are solved.
I also tested if I was able to reproduce the issue with close after fill in
whidbey beta 1 which I was. So although my code is working I still believe
there is a problem here.


Angel Saenz-Badillos said:
Morten,
I wish I knew what the report number for this was, the process for this was
something along the lines of
Me> Does anybody know why this code is behaving this way?
Response> This works fine for me in SP1, can you try 1proc?
Me> Verifies it works with SP1 in 1proc 2proc and 4proc machine and respond
to newsgroup thread.

As you can probably gather I really have no idea what is going on. I will
try to repro this with a close after fill, if I can still get it to repro in
v1.1 sp1 I will do the same process again. I hope that this also repros in
the whidbey beta 1 since the process is much easier for current products
when there is a possible workaround for the bug.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Morten Nielsen said:
Hi Angel,

It seems that the code I posted works when using v1.1 Service Pack 1, but if
I add a _connection.Close() after filling the dataset the thread just hangs
here instead, and only finishes when the main thread no longer waits for the
Readline. Could you please refer me to the report number adressing this
problem?

The _connection.Close() is not an actual problem I have, I just found out by
coincidence, but I still would like to get an explanation.

I won't be able to test service pack 1 in the actual code where I first
encountered this problem right now, but I will let you know when I have
tested it.


Angel Saenz-Badillos said:
Morten,
It looks like this issue has already been fixed for v1.1 in Service pack 1
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055

let me know if this fixes your issue.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




You are right, it wouldnt make sense. I really can't think of anything
that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it
does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




message
Hi,
It is correct that I'm not running into an exception, but I don't
actually
use _connection in the main thread. I only instatiate the
OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated
in
the main thread. If it is a lock like you suggest I would expect to see
the
same behavior if the connection was instatiated in any other thread than
the
one using it.

I originally posted this question on the OleDb newsgroup but there are
no
answers yet, so I would appreciate any help I could get here.


:

Morten,
If I understand your concern correctly you are not running into an
exception
right? the only problem you have is that DataTester does not run until
the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup if they
are
doing anything like this.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
A

Angel Saenz-Badillos[MS]

Morten,
Thanks for following up on this, I have tried reproing in my current whidbey
bits (post beta 1 unfortunatelly) and have not been able to repro. If you
can post your exact code I will give it another try. I will also try to set
up a beta 1 machine in the next few days.

Unfortunatelly I am at a loss of what could be happening here and I don't
know who to ask...

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Morten Nielsen said:
Hi Angel,

I have now tested the SP1 with my production code and the problems we have
found here are solved.
I also tested if I was able to reproduce the issue with close after fill in
whidbey beta 1 which I was. So although my code is working I still believe
there is a problem here.


Angel Saenz-Badillos said:
Morten,
I wish I knew what the report number for this was, the process for this was
something along the lines of
Me> Does anybody know why this code is behaving this way?
Response> This works fine for me in SP1, can you try 1proc?
Me> Verifies it works with SP1 in 1proc 2proc and 4proc machine and respond
to newsgroup thread.

As you can probably gather I really have no idea what is going on. I will
try to repro this with a close after fill, if I can still get it to repro in
v1.1 sp1 I will do the same process again. I hope that this also repros in
the whidbey beta 1 since the process is much easier for current products
when there is a possible workaround for the bug.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




Hi Angel,

It seems that the code I posted works when using v1.1 Service Pack 1,
but
if
I add a _connection.Close() after filling the dataset the thread just hangs
here instead, and only finishes when the main thread no longer waits
for
the
Readline. Could you please refer me to the report number adressing this
problem?

The _connection.Close() is not an actual problem I have, I just found
out
by
coincidence, but I still would like to get an explanation.

I won't be able to test service pack 1 in the actual code where I first
encountered this problem right now, but I will let you know when I have
tested it.


:

Morten,
It looks like this issue has already been fixed for v1.1 in Service
pack
1
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055

let me know if this fixes your issue.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




You are right, it wouldnt make sense. I really can't think of anything
that
we may be doing to cause this, will have to investigate.

I tried to repro this and it works every time against v1.1, however it
does
not repro against v2.0 beta.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/




message
Hi,
It is correct that I'm not running into an exception, but I don't
actually
use _connection in the main thread. I only instatiate the
OleDbConnection.
So I can't see why the main thread should have any kind of lock on
_connection. Still this only happens when the connection is instatiated
in
the main thread. If it is a lock like you suggest I would expect
to
see
the
same behavior if the connection was instatiated in any other
thread
than
the
one using it.

I originally posted this question on the OleDb newsgroup but
there
are
no
answers yet, so I would appreciate any help I could get here.


:

Morten,
If I understand your concern correctly you are not running into an
exception
right? the only problem you have is that DataTester does not
run
until
the
_connection is no longer being used in the main thread?

Sounds like somebody is locking the oledb native connection to make it
thread safe, you may want to ask in the native Oledb newsgroup
if
they
are
doing anything like this.
confers
no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
G

Guest

Hi Angel,

the code I have used is very similar to my original post, but the full code
is:

using System;
using System.Data;
using System.Data.OleDb;
using System.Data.SqlClient;
using System.Threading;

namespace TestDataAdapter
{
class Class1
{
private static OleDbConnection _connection;

[STAThread]
static void Main(string[] args)
{
_connection = createConnection();
Thread dataThread = new Thread(new ThreadStart(dataTester));
dataThread.Start();

Console.ReadLine();
}

private static OleDbConnection createConnection()
{
string connectionString = "Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security Info=False;Initial Catalog=Northwind;Data
Source=127.0.0.1;Use Procedure for Prepare=1;Auto Translate=True;Packet
Size=4096;Use Encryption for Data=False;Tag with column collation when
possible=False";
OleDbConnection conn = null;
try
{
conn = new OleDbConnection(connectionString);
conn.Open();
Console.WriteLine("Connection opened successfully");
}
catch (Exception)
{
Console.WriteLine("Connection could not be opened");
}

return conn;
}

private static void dataTester()
{
DataSet ds = new DataSet();

string sql = "select LastName from Employees";
OleDbCommand cmd = new OleDbCommand(sql, _connection);
OleDbDataAdapter adapter = new OleDbDataAdapter(cmd);
adapter.Fill(ds);

Console.WriteLine(ds.Tables[0].Rows[0].ItemArray[0]);
cmd = null;
_connection.Close();

Console.WriteLine("DataSet filled");
}
}
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top