Re: Column <ColumnName> does not belong to table <TableName>

  • Thread starter Thread starter Cor Ligthert [MVP]
  • Start date Start date
Um, yes, thanks. Searching for 80070057 *does* return hits - I should have
explained a little better, perhaps.

It seems that error code 80070057 is somewhat of a generic error code. I've
seen it in my own code on occasion in a variety of situations - COM+ problems
and other types of data access issues caused by my own foolishness. None of
those are applicable in this case as far as I can tell, and indeed, none of
the hits on the search you pointed to are relevant to the specific issue I'm
experiencing. The most applicable one is "Standard COM Error 80070057. One
or more arguments are not valid error." Except that all the arguments *are*
valid since the column in question is in the table in question.

I threw the 80070057 message in there in the interests of completeness, but
I don't think it's the central issue. In fact, when you add the other part
of the error message I quoted to your search (the "System.Data" part that I
posted) you get 4 hits, none of which match.

If we assume that perhaps the error message is being generated by invliad
arguments, it begs the question: why are the arguments invalid? - the column
*does* belong to the table.
--
Thanks;
cori


Cor Ligthert said:
Cori,

You told there was no information on internet but this simple search on MSDN
gives quiet a few pages of text with answers.

http://lab.msdn.microsoft.com/search/refinement.aspx?__VIEWSTATE=&query=80070057

Cor
Click to expand...
 
I've had the same issue with the error being thrown at random and it is extremely frustrating. I know the column does exist. Resetting IIS or just replacing the dll resolves it. I could just create the query every session but I'm trying to utilize the dataset in cache but this random error is making me double think it. Has anyone found an answer?

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com
 
Hi Cori,

Do you still monitor on this issue?
According to your description, I understand that you are using ADO.net on
Classic ASP site and often receive an error said "column name and table
name change depending on what page is being accessed". Resetting IIS
resolves it. Please don't hesitate to correct me, if I have misunderstood
anything here.

We need to perform more research on this issue . We will reply here as soon
as possible.
If you have any more concerns on it, please feel free to post here.

Thanks for your understanding!
Best regards,
Wen Yuan
 
Hello WenYuan;

Yes, I'm still watching ;)

A little more detail for your research: we have a standard ASP site that
instantiates a .Net DLL as a COM component (using Server.CreateObject()) for
backend work, primarily for database access (using ADO.Net).

Resetting IIS universally resolves the issue (or has so far, at least).

The error we see says "Column <ColumnName> does not belong to table
<TableName>". The values of ColumnName and TableName vary depending on what
page is being accessed when the error occurs, and there is no consistency to
it at all that we've been able to discover. Universally the column
referenced in the error message does indeed exist in the referenced table.

Is that a better level of detail?
 
Hi Cori,
Thanks for your information.

I have checked on bug list and KB, but this issue has not been recorded in
there. In general, the error message "Column <ColumnName> does not belong
to table <TableName>" occurs after we rename the columns of a DataTable
object in the DataSet. This is a product issue and has been fixed in
ado.Net 2.0.
http://support.microsoft.com/kb/815545/en-us
[An unhandled exception of the 'System.ArgumentException' type occurs after
you rename the columns of a DataSet object]

We really haven't met your issue before. For this reason I will consulting
with our product team on it. Additional, would you please paste the whole
error Page in newsgroup include the error message and related code. So that
we can performed further analyze.

Have a great weekend!
Sincerely,
Wen Yuan
 
This is an intermittent issue, but the next time we see it I'll collect the
whole error message and post it here.

I can confirm at we're not performing the actions mentioned in the KB
article you point to. I should note that not only has someone else mentioned
in this thread that they're seeing it, but I've seen the error message
mentioned elsewhere, often is response to binding to a datagrid. In our
case, since we're not using ASP.Net, we're generating an ADO.Net DataSet and
creating an array of objects based on the DataSet and looping through those
objects. We believe that the error is being generated when we fill the
DataSet before the page code that creates the table of objects even has a
chance to execute.
 
Hi Dale,

I afraid this is the root cause, if you haven't install SQL Express by VS
2005 disk, SQL 2005 articles will not be installed in Microsoft VS 2005
Document. Please feel free to reply me if there is anything we can help
with. I'm very glad to assist you.

Have a great day!
Sincerely.
Wen Yuan
 
Hi Cori,
Thanks very much for your reply.

I have consulted with our product team member. According to their
subscription, I'm afraid it is not recommend you use ADO.net in Class ASP
application. Additional, it is very hard to trouble-shot such issue.
ADO.net dll library should only be used in .Net Framework application.
Below is the reply from our product team. Please feel free to reply me if
there is anything we can help with. You are welcome.

Best regards,
Wen Yuan
===========================================================================

First, this is not an intended scenario for ADO.NET.

Aside from that, even with managed ADO.NET code, I have seen this error
occur in scenarios like you describe, where it doesn't seem to make sense.
In each case, it was due to improper usage of the components, particularly
multithreaded usage of components that do not support it. SqlConnection
(all operations) and DataTable (write operations) are good examples of
operations that are not threadsafe. With one particular customer, we were
able to track down a scenario where multithreaded usage of SqlConnection
was causing resultsets to get mixed up, so that what came back to the
client on one request was actually the results for a different request that
was being made on the same connection at the same time, for another thread.
These are the kinds of things that can cause errors like you describe.

It's difficult to track down these kinds of issues, although you can make
an attempt from memory dumps taken a the point of the exception. Frequently
that just shows you the aftermath of the problem, and doesn't help track
down the root cause. Typically an architecture and code review will
highlight general improper usage. In the case I mentioned above, the
customer was storing a SqlCommand in ASP.NET session state. Once they
changed this to use local SqlCommands whenever they needed one, their
problems went away .

Thanks,
 
Hi Cori,

Just want to check if you have any concern. Please feel free to let me know
and we will follow up.
We are glad to work with you.

Have a great day!
Sincerely,
Wen Yuan
 
Back
Top