Sporadic Error: Cannot find table 0

The application is developed in ASP.Net with a SQL Server database.

Essentially, the application uses a single shared Connection object for
all users logged into the system. The connection object is
opened/closed for each transaction.

The error - System.IndexOutOfRangeException: Cannot find table 0 -
occurs on one page that accepts a single piece of data from a textbox.
This data is then passed to the business logic classes (in VB.Net) and
is queried against the database.

According to the stack trace, the error occurs at:
System.Data.DataTableCollection.get_Item(Int32 index) +79

Out of 100 data entries, this error will appear once or twice. Note
also that when the user enters the same piece of data that caused the
initial run-time error, the second entry executes OK!
Any suggestions?

Thanks:

Pat

POL8985

Pat:
You haven't provided nearly enough information to successfully diagnose the
problem. Somewhere you have a dataset where you are doing something like:

dim dt as DataTable = ds.Tables(0)

or

ds.Tables(0).[SOMETHING]

but ds.Tables(0) isn't a valid table..it's null/nothing and when you try to
access it an index out of range.

While I don't think the shared connection is necessarily a problem in this
case, depending on how it's implemented, this could likely cause you other
types of problems down the road...again, just assuming without seeing any
code.

Karl


--
MY ASP.Net tutorials
http://www.openmymind.net/


"POL8985" <> wrote in message
news: ps.com...
> The application is developed in ASP.Net with a SQL Server database.
>
> Essentially, the application uses a single shared Connection object for
> all users logged into the system. The connection object is
> opened/closed for each transaction.
>
> The error - System.IndexOutOfRangeException: Cannot find table 0 -
> occurs on one page that accepts a single piece of data from a textbox.
> This data is then passed to the business logic classes (in VB.Net) and
> is queried against the database.
>
> According to the stack trace, the error occurs at:
> System.Data.DataTableCollection.get_Item(Int32 index) +79
>
> Out of 100 data entries, this error will appear once or twice. Note
> also that when the user enters the same piece of data that caused the
> initial run-time error, the second entry executes OK!
> Any suggestions?
>
> Thanks:
>
> Pat
>

Thank you, Karl, for your help.

Technically, the IndexOutOfRangeException 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

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" <> wrote in message
news: ups.com...
> Thank you, Karl, for your help.
>
> Technically, the IndexOutOfRangeException 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
>