New Question: Loading ADO.Net Datatable to objectdatasource

[David]

     Could someone please explain to me how to do the following.  I have the following ADO.NET table created in the report source (shown below).  How do I make the data available in a report. 

     Our company has been creating a DataSet.xsd in the solution and then add a report dataset that is set to the table in the DataSet.xsd.  Then we add a ObjectDataSource, set it's DataSource to the DataSet in the report and then bind the report (ie: set the report datasource) to the ObjectDataSource.  This will make it's fields available in the report.  Note: We load the ObjectDataSource in the report source, ie: DataSet.ObjectDataSource.Load(dtSource).  The problem with this method is that it requires you to add a new table for your report to the DataSet.xsd everytime you want to pass something that hasn't already been created to the xsd.

     Is there a way to just add a blank dataset to the report, set a ObjectDataSource.DataSource to the dataset and then just load the dataset in the source?  ie:  Skip the DataSet.xsd part?

dt As New DataTable
Dim row As New DataRow

dt.Columns.Add("Id", GetType(Integer))
dt.Columns.Add("FirstName", GetType(String))
dt.Columns.Add("LastName", GetType(String))

row = dt.NewRow()

row("Id") = 1
row("FirstName") = "John"
row("LastName" = "Smith"

dt.Rows.Add(row)

 

Thanks in advance.

 

 

[David]

I suspect we look at this slightly different. The real purpose of the .XSD is simply to construct the required "glue" to read/write your data from you data source.  A .XSD describes your data providing the details of column names, data types, and similar items.  A Data Table Adapter provides the mechanism to read/write the data from the associated data table.  The entire .XSD is a physical representation of the DataSet data type.

There is nothing stopping you from skipping a .XSD entirely.  You could construct your own business objects to read/write your "objects".  The ObjectDataSource is fully capable of interfacing with classes directly and does not require a .XSD.

Now with that said, there are good reasons to use .XSD's.  The sheer convenience of being able to easily edit reports is a nice thing.  When you start using your own business objects you run into cases where your report becomes unbound from the class it was bound to because of a program change.  A re-compile fixes this most of the time however if you missed something, your project suddenly has hundreds of errors.  Yes these are easily fixed however they can prove troublesome to less experienced folks.  I have taken to using "FakeRead" methods on my classes so I can quickly bind to a method that always returns a list of objects for the class I am writing.  (Think development stub)

 

 

[David]

David:  I am only looking to use this method for static values.  I was just curious if there is an alternative to using report parameters.  I thought I could create a table via ADO.NET and add one row with various columns (add more columns later if required) and simply pass that one row of static values to the report.

what is the syntax to do that.  I thought it would be something like Me.ObjectDatasource  = Datatable but that doesn't seem to be a possibility.

 

[David]

Uh, a simple solution would be to add your datatable to a dataset.

Something like:

DataSet dDS = new DataSet();

dDS.Tables.add(dt) ; // add your datatable to dataset

return dDS ; //return dataset for direct binding to objectdatasource.Datasource