locked
Too many columns reported from table adapter RRS feed

  • Question

  • I'm using a table adapter's GetData() method to return a data set that is produced from a stored procedure that uses a dynamic query.  The resulting data set returns too many columns and the incorrect data.  Does anyone have any suggestions?


    Thanks.
    Tuesday, November 18, 2008 7:10 PM

Answers

  • I think I found the problem.  In my stored procedure, I had several other transactions, some dynamic, some not.  I moved the final select statement (the one I was interested in) to a procedure by itself.  The data and column count are now correct.

    Thank you for your help konikula.
    • Marked as answer by sage4 Tuesday, November 18, 2008 9:37 PM
    Tuesday, November 18, 2008 9:36 PM

All replies

  • Yyes

    Rregards
    Tuesday, November 18, 2008 7:42 PM
  • Ok, how many data is there in stored procedure? Or isn't there some bug inside, producing such garbage and eating probably other data in recursive join with another bugs?
    Tuesday, November 18, 2008 7:59 PM
  • The procedure runs fine in management studio.  The query pulls data from two different tables using an inner join. 
    I should clarify about the data.  The data that is returned is correct, but columns are returned without being renamed like I have in the query using as.  By too many columns, there are columns being returned more than once.
    Tuesday, November 18, 2008 8:09 PM
  • Can you show us that procedure?

    • Proposed as answer by konikula Tuesday, November 18, 2008 9:39 PM
    Tuesday, November 18, 2008 8:24 PM
  • Pardon also for my introduce :) Your first post is actually very funny...
    Tuesday, November 18, 2008 8:26 PM
  • I wasn't trying to be funny, but okay thanks.

    Like I have already posted the procedure runs fine in management studio, and previews fine in the data set designer.  I was/am hoping for an answer similar to "dynamic stored procedures wont' work with table adapters/data tables because you have to do this..." or something like that.
    I suspect the problem lies in my query returning a variable number of columns depending on the data, and the table adapter expecting a fixed number.  I am running test data and the number of columns returned are considerably off.  Some of the columns are being returned more than once.
    Tuesday, November 18, 2008 8:36 PM
  • But until we check procedure itself, we don't know if we have to relay on its validity, and so if we have to continue with suppose something is wrong with vb mechanism. Simply because we can't relay on m.s.
    • Proposed as answer by konikula Tuesday, November 18, 2008 9:39 PM
    Tuesday, November 18, 2008 8:47 PM
  • How you done that adapter is awaiting fixed width of return?
    Tuesday, November 18, 2008 8:48 PM
  • I think I found the problem.  In my stored procedure, I had several other transactions, some dynamic, some not.  I moved the final select statement (the one I was interested in) to a procedure by itself.  The data and column count are now correct.

    Thank you for your help konikula.
    • Marked as answer by sage4 Tuesday, November 18, 2008 9:37 PM
    Tuesday, November 18, 2008 9:36 PM
  • Um, can't you please just post your proc here? Or mismatched parts for others to have some leading?
    Tuesday, November 18, 2008 9:38 PM