Pat,
I'm still not sure that the problem isn't simple logic (as in the record
doesn't exist), but as I said, depending on how your data access class is
handled within your two business layers, there could certainly be problems.
First of all, the fact that you have 2 assemblies for your business layer,
each having a separate instance of the data access class isn't likely an
issue, so let's simplify it and say you have 1 assembly (dll) for your
business logic which has a global data access class instace
If your global data access class instance is shared/static and you aren't
implementing some type of locking, you risk having problems (you most
certainly will actually). Remember, ASP.Net is a multithread environment,
and each request will be serviced by an individual thread. however,
shared/static variables are shared by all threads, so two or more threads
(if more than 1 user requests a page) might try to open the same connection,
then one might close it before the other is finished with it. All this
depends a lot on how you are managing the instance within your business
assembly as well as what the data access class itself does. However, if you
haven't considered this, simply creating a new instance of the data access
class as needed might resolve your problem. That is, don't have a
global/shared one, create and dispose as needed. This is how to best allow
ADO.Net's connection pooling to work, open connections as late as possible
and close them as soon as possible. You might be doing this, but if it's in
a shared/static instance, you'll run into threading problems.
Going back to the first issue, have you tried to capture the user inputs for
when the exception is generated? Just incase the error is logical?
Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/
"POL8985" <po*****@njit.e du> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...
Thank you, Karl, for your help.
Technically, the IndexOutOfRange Exception should never occur because
the data being entered in the ASPX page is actually in the database
(and should return the corresponding set of records in my
DataSet.Table(0 ))! We've actually never paid explicit attention to
connection pooling and hope this would be key to solving our problem.
Allow me to give you a bit more background into the application.
The ASP.Net application references two DLLs that provide 100% of the
business logic. Each of these DLLs performs all SQL Server
transactions via a data access class we wrote. Each DLL has one global
instance of this data access class (with the same connection string).
The data access class uses a single connection object that is
open/closed with each transaction.
I know that connection pooling is automatically handled by ADO.Net, but
how would I explicitly use it to solve this problem?
Thanks again:
Pat
