Is first datatable in dataset reserved for something?

[Karim]

I have a stored procedure that's called in a loop with a different
paramater each time and a typed dataset that gets filled through a
sqldataadapter as in:

this.sqlDataAdapter2.Fill(dsFunding2, "Table" + i.ToString());

I know that the first iteration of the stored procedure returns 18 rows.
The problem is that when I do dsFunding2.Tables[0].Rows.Count, it returns 0
instead of 18. When I do dsFunding2.Tables[1].Rows.Count, I get 18.
And later the rows count for each iteration seems ok. The problem is with
the first datatable.

I expected datatable[0], the first datatable, to contain the first
resultset. Is this normal behaviour?

Karim

 

[William Ryan]

But a breakpoint there and check out what Table[0] is, and/or use a Named
reference. In your proc, is there something like a Go statement or could
you possibly be firing two queries? If not, table 0 should be the one you
want. Another thing might be preceeding code, if you are adding a table to
it somewhere. But no, table[0] isn't reserved for anything.

 

[William \(Bill\) Vaughn]

Yup. Perfectly normal when your stored procedure returns more than one
rowset. ADO.NET should ignore empty resultsets (those with no rowsets) when
it constructs the data tables, but if there is a SELECT in the SP, it might
think there is a rowset to deal with and constructs a DataTable to hold the
rows.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________

 

[Karim]

Yup. Perfectly normal when your stored procedure returns more than one
rowset. ADO.NET should ignore empty resultsets (those with no rowsets) when
it constructs the data tables, but if there is a SELECT in the SP, it might
think there is a rowset to deal with and constructs a DataTable to hold the
rows.

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

However after setting the datagrid's datasource to the new dataset, the
datamember to the first datatable name, there's no datagrid on the webpage.
I set a breakpoint just before the databind() and verified the dataset has
rows and data but nothing shows up in the grid. I changed the background of
the datagrid to yellow.
(Although I don't know if at least a datagrid outline shows up if no data
is present) The grid is a brand new one.

Karim

 

[William Ryan]

If it doesn't have rows, then no, it won't show at all. Are you setting the
DataSource to the new table that definitely has rows?

Yup. Perfectly normal when your stored procedure returns more than one
rowset. ADO.NET should ignore empty resultsets (those with no rowsets) when
it constructs the data tables, but if there is a SELECT in the SP, it might
think there is a rowset to deal with and constructs a DataTable to hold the
rows.

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

However after setting the datagrid's datasource to the new dataset, the
datamember to the first datatable name, there's no datagrid on the webpage.
I set a breakpoint just before the databind() and verified the dataset has
rows and data but nothing shows up in the grid. I changed the background of
the datagrid to yellow.
(Although I don't know if at least a datagrid outline shows up if no data
is present) The grid is a brand new one.

Karim

 

[Miha Markic]

Hi Karim,

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

Fill was filling table with other name that existing one. That's why you've
ended with two tables.

However after setting the datagrid's datasource to the new dataset, the
datamember to the first datatable name, there's no datagrid on the webpage.
I set a breakpoint just before the databind() and verified the dataset has
rows and data but nothing shows up in the grid. I changed the background of
the datagrid to yellow.
(Although I don't know if at least a datagrid outline shows up if no data
is present) The grid is a brand new one.

Try binding directly to table instead dataset/member.

 

[Karim]

If it doesn't have rows, then no, it won't show at all. Are you setting the
DataSource to the new table that definitely has rows?

Yes.. I inspected the first datatable just before calling databind and it
has rows.

Karim

Yup. Perfectly normal when your stored procedure returns more than one
rowset. ADO.NET should ignore empty resultsets (those with no rowsets) when
it constructs the data tables, but if there is a SELECT in the SP, it might
think there is a rowset to deal with and constructs a DataTable to hold the
rows.

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

However after setting the datagrid's datasource to the new dataset, the
datamember to the first datatable name, there's no datagrid on the webpage.
I set a breakpoint just before the databind() and verified the dataset has
rows and data but nothing shows up in the grid. I changed the background of
the datagrid to yellow.
(Although I don't know if at least a datagrid outline shows up if no data
is present) The grid is a brand new one.

Karim

 

[Karim]

Hi Karim,

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

Fill was filling table with other name that existing one. That's why you've
ended with two tables.

I don't understand what you're saying. The SP returns a single result set
and therefore I should have one datatable, regardless what I call the
table.

Try binding directly to table instead dataset/member.

Which table?

Karim

 

[Miha Markic]

Hi Karim,

Hi Karim,

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

Fill was filling table with other name that existing one. That's why you've
ended with two tables.

I don't understand what you're saying. The SP returns a single result set
and therefore I should have one datatable, regardless what I call the
table.

Yes, it returns one datatable. But the datasets can contain one or *more*
tables which are identified by their names.
So, Fill method has to decide into which table in dataset it should copy the
returned data or create a new table if suitable table (=table name) does
not exist.
IOW, if you have a dataset with one table named Tubo and you do Fill
operation with commandtext SELECT * FROM AnotherTubo into the same dataset
(adapter.Fill(dataset1) ) you'll end up with dataset with two tables - tubo
and anothertubo.

Which table?

The table you want to bind to.

 

[mklapp]

I believe the act of genning the dataset sets aside a
table named the source table or Stored Procedure
or 'something'. If you do not name a table in the Fill
method, I believe the rows go to the 'default' table.

This is not the result of an intensive investigation,
just some preliminary conclusions I reached based on some
observations.
I name All my tables now except where relations are
used. Then I use the tables named in the genned xsd file.
(the relationship thing above, has not been tested yet)

If you must use the index to step through the collection,
I think Table has a property "TableName", so you could
index through the collection checking each tablename.

mklapp

-----Original Message-----

If it doesn't have rows, then no, it won't show at all. Are you setting the
DataSource to the new table that definitely has rows?

Yes.. I inspected the first datatable just before calling databind and it
has rows.

Karim

Yup. Perfectly normal when your stored procedure returns more than one
rowset. ADO.NET should ignore empty resultsets

(those with no rowsets)
when

it constructs the data tables, but if there is a

SELECT in the SP, it
might

think there is a rowset to deal with and constructs

a DataTable to hold
the

rows.

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

However after setting the datagrid's datasource to the new dataset, the
datamember to the first datatable name, there's no

datagrid on the
webpage.

I set a breakpoint just before the databind() and verified the dataset has
rows and data but nothing shows up in the grid. I

changed the background
of

the datagrid to yellow.
(Although I don't know if at least a datagrid outline shows up if no data
is present) The grid is a brand new one.

Karim

.

 

[Karim]

Hi Karim,

Hi Karim,

On Tue, 9 Dec 2003 13:15:24 -0800, William (Bill) Vaughn wrote:

The sp returns a single rowset.
I moved from a strongly typed dataset to the generic DataSet. datatable[0]
now has the first sp iteration. So far so good.

Fill was filling table with other name that existing one. That's why you've
ended with two tables.

I don't understand what you're saying. The SP returns a single result set
and therefore I should have one datatable, regardless what I call the
table.

Yes, it returns one datatable. But the datasets can contain one or *more*
tables which are identified by their names.
So, Fill method has to decide into which table in dataset it should copy the
returned data or create a new table if suitable table (=table name) does
not exist.
IOW, if you have a dataset with one table named Tubo and you do Fill
operation with commandtext SELECT * FROM AnotherTubo into the same dataset
(adapter.Fill(dataset1) ) you'll end up with dataset with two tables - tubo
and anothertubo.

But I am putting the first resultset into a new dataset. Why do you think I
have an existing datatable?

The table you want to bind to.

Which I am already doing and which I mentioned in my post.

Karim