One DataTable class in two datasets - design-time support

[Jiøí Neu¾il]

Hi, I created two datasets in dataset designer in VS 2005. Both of them
contain the same datatable. I think, having two classes for one DB datatable
is stupid and badly maintaining. So I need manually add DataTable class from
first dataset to second. So I modified designer.cs of second dataset and I
added datatable from first dataset:
I added this code to InitClass() method of second Dataset:
this.UCET = new ageu.DataLayer.dsFakturace.UCETDataTable();
base.Tables.Add(this.UCET);

Ucet is DB table, which I need in both datasets. dsFakturace is first
dataset. This is working solution, design -time databinding is working. But,
designer sometimes regenerate designer.cs and my changes are lost. Is there
any better approach to do this?

Thank you.

 

[RobinS]

You should never change the designer code, because when it gets
regenerated, you lose your changes. As you've found.

Can't you just add the first datatable to the second dataset? Can you copy
and paste it, or (better yet) just recreate the dataset with the two tables
in it? Seems like that would take less time than you've already spent on
it.

Robin S.

 

[Jiøí Neu¾il]

No, why should I have one datatable 2 times (or more) in code??? I need add
other methods to this datatable, so in your approach I need write this
methods twice! (or more). And any change (and bug repair) I have to do on
two places! This is the worstest approch I could choose....

 

[RobinS]

I guess I don't understand your problem. I thought you said you have two
strongly typed datasets, each with one table, and you wanted to combine
them.

So do you want to combine them at run time rather than at design time? Is
that the point?

And I'll repeat this: you should never change the designer code, because if
it gets regenerated, your changes will be lost.

If the designer code is a partial class, you can probably *add* to it by
adding another class to your project and declaring it a partial class with
the same name. This will not be wiped out if the designer code is
regerated, and will be considered part of the same class.

If I'm completely offbase, please post more information.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-------------------------------------------

 

[Jiøí Neu¾il]

Hi,
I have in my database datatable called for example employee. I have two
dataset classes (two xsd schema files), where are some tables (dataset are
differents) and I need in both of them employee datatable. Easiest way is to
drag and drop this datatable from server explorer to both datasets, but in
this case I will have this datatable in my code twice. So if I add some
methods to employee datatable in first dataset, then I have to add the same
code to employee datatable in second dataset....Is this clear?
Now imagine situation, I have 10 datasets (which are completely
different)...and I need in all of them my employee datatable, so If I add
one method to first's dataset employee datatable, I have to copy and paste
this code to next nine employee datatable classes...

 

[RobinS]

I do understand what you're saying, and there's no easy way to do what
you're talking about.

Maybe you could create the strongly typed datasets yourself manually and
not in the designer, and add in the code for the second datatable yourself
into each dataset.

I was talking to a Microsoft MVP last week about strongly typed datasets
versus business objects. She said she uses the datasets, but they generate
their own (Dave Sceppa explains it in his book, has something to do with
XML; if you can't find anything in MSDN or Google, post back and I'll see
if I can post some info about it) and then they remove the table adapter,
because they use all stored procs to do the updates. Presumably if that was
possible, then you could automate that (as she has) and then add in the
code for the datatable.

Sure, it would be replicated, but if it was in an automated procedure, who
cares?

If you need more info, post back, and I'll track her down and ask her more
q's about this. I probably won't be able to get an answer from her until
next week though, just FYI.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------