I concur.
The Fill method does use the DataReader behind the scenes. And, no, you
can't use an open connection to execute Fill or anything else--not until ADO
2.0 when MARS (might) solve this issue. Shared connections don't work
anyway. The system needs to manage a separate context for each operation.
You need to open and close connections as they are used. Fill will do this
for you IF you have not already opened the connection when it's executed.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"NuTcAsE" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> This is classic synchronization problem. Each user is operating on a
> different thread, but the are using the same connection instance. If
> your m_Connection is static, there can be a synchronization problem.
> Consider this:
>
> 1. Uer A logs in
> 2. User B logs in
> 3. User A executes ExecuteSPDS
> 4. Before User A's ExecuteSPDS is finished UserB executes
> ExecuteScalarQuery1. KABOOOM. The connection is already open and being
> used soUserB will get an error.
>
> First suggestion dont use a global connection. You gain nothing by doin
> that and its bad programming practice. Connections should be short
> lived and disposed off as quickly as possible. If you have to use a
> global connection use locking like DalePres suggested. Wrap your
> function with a lock { } statement. But if you do go down this approach
> be warned: if a long running function already has a lock on the
> connection, all other connection will wait till that function is
> finished, bringing your app's performance down.
>
> NuTcAsE
>