DataSet Question

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Hi,

I am trying to solve a problem with a DataSet issue I am having. In my app
the user selects certain options and based on those options it goes out to
the db to get data based on those options. This data will be used in
different Business Objects (Business Rules and Reporting). I have decided
to use DataSets as the data container because the data is dyncamic and will
change based on user selections which I could not simulate in a custom
object. Also the reporting engine is designed to use a dataset. Based on
each user selection the app goes to the db and retrieves data at different
times. My question is how I can structure the data retrieved into one
dataset? I was thinking of creating a dataset at design time which would
represent the data that is present no matter what the user selects and then
at retrieval of other data add the new data to the dataset. I really do not
like this option because I would have to loop through the dataset retrieved
and compare it the design time dataset and if the columns does not exist in
the design time dataset then add the new columns and data to the dataset. I
also thought that I could just add each dataset by merging the datasets
together after each retrieval. However, I really rather have a dataset with
one datatable not several. Hope I explained my problem.

Thanks
 
Mike,

I am confused and wonder if some unfortunate terminology in Visual Studio is
confusing you. In case, let me explain...

At design time a "DataSet" inside Visual Studio (such as "Generate Dataset"
context menu option) refers to a strongly typed dataset. This is a normal
class that is added to your project to provide strongly typed access. You
can see it if you set Solution Explorer to "Show All Files" (a button at the
top) and expand the plus at the XSD.

The other type of DataSet is the "normal" or "untyped" dataset. This dataset
is dynamically created at runtime. The strongly typed dataset inherits from
the untyped dataset so you can always access a strongly typed dataset
through untyped means, which is the biggest drawback of the strongly typed
dataset.

For your problem the strongly typed dataset won't work becuase you're
creating the structure at runtime. You'll have to use the untyped dataset,
and probably string fieldnames for access - which is unfortunate both from a
robustness and a performance standpoint.
I was thinking of creating a dataset at design time which would
represent the data that is present no matter what the user selects and then
at retrieval of other data add the new data to the dataset.
Click to expand...

Do you mean that you would be combining typed and untyped access? It won't
confuse .NET but will confuse later programmers.
I really do not
like this option because I would have to loop through the dataset retrieved
and compare it the design time dataset and if the columns does not exist in
the design time dataset then add the new columns and data to the dataset.
Click to expand...

No, if they are in your resultset, they'll be in your untyped dataset.
I also thought that I could just add each dataset by merging the datasets
together after each retrieval. However, I really rather have a dataset with
one datatable not several.
Click to expand...

I don't see where merging datasets fit in. If you have multiple tables you
can retrieve them into a single dataset.
Hope I explained my problem.
Click to expand...

I am guessing I misunderstood it. Are you trying to get different columns
from different SQL statements? If so, can you possibly avoid that
architecture?

Kathleen


Thus, I am confused by your statement
 
Thanks for the post. I apologize for not using typed and untyped datasets
terminology. In my app I need to have data from multiple tables from a
db(based on user input) to be in one dataset for my Business Objects. At
design time I know 80% of the data structure and the 20% is known at
runtime. So, initially I thought about creating a typed dataset with 80% of
the data structure and at runtime I will add the rest of the data. The
problem with this approach it is not flexible. Also, I am struggling with
manually adding data (code not using data adappter) to the typed dataset. I
guess my problem is I really want one data table containing all of my data
from multiple tables. This data is bunch of values for business
calculations. The other approach I thought of was using an untyped dataset
where I can merge datasets of data. This approach will work however it will
be difficult to map to the data by my business objects. I am looking for a
flexible approach.

Thanks
 
Mike,

If I am following you, what real benefit do you get from building part of
the structure at design time?
 
After thinking about it - none. I have come up with these two designs:

1) Use an untyped DataSet and add new data to it based on user input (new
tables)
- the negatives to this approach is some overhead and mapping to the
correct data
2) Use a HashTable and add data to it based on user input (loop through the
datatables)
- the negatives to this approach is will not have the benifits of the
DataSet (XML...)
- will need to create some custom code

I would like to use the first option because I have a report engine that
creates reports based on dataset data. Another area that I have a question
is it bad practice to create a dataset at runtime using code not based on db
structure, it will be strictly built in code by manually adding tables and
rows.

Thanks
 
Mike,

I don't see where a mapping problem comes in if the new data is in new
tables with the first approach, but other than that it seems you've more or
less got the practical ones covered (I'm suggesting that emitting a new
class at run time is not in the practical realm). You can also add new
columns to existing tables at runtime, but you would have to shove the data
into those columns manually. Overall, if you are gaining from the DataSet,
I'd suggest staying with it.
 
Back
Top