By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,279 Members | 2,112 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,279 IT Pros & Developers. It's quick & easy.

GetParentRow(s) or GetChildRows?

P: n/a
Could someone fill me in on the difference between the following three
DataRow methods:

GetParentRow
GetParentRows
GetChildRows

I'm guessing the difference between the first two is that one returns an
array while the other returns a single Row, which leads me to wonder, what
would happen if this option were used but there were more than one parent
row. On that note, in a relationship, what defines one row as a parent and
one as a child? Is it that multiple child fields can refer to a single parent
field and from this, the engine somehow deduces which side is the child and
which is the parent? From what I see above, it's possible for a table to have
multiple parents. How would this work? When you create a relation between
tables in a dataset, if you don't specify which side is which, what rules are
used to decide?

Thanks...
Jul 21 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Ben,
The parent & child is defined when you define the DataRelation object either
in code or via an XSD.

All three functions expect a DataRelation (either name or actual object) to
determine which relationship to resolve.

For a complete explanation of advanced features of Datasets, such as parent
rows & child rows, I would strongly recommend you read David Sceppa's book
"Microsoft ADO.NET - Core Reference" from MS Press. As it is a good tutorial
on ADO.NET as well as a good desk reference once you know ADO.NET.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:C1**********************************@microsof t.com...
Could someone fill me in on the difference between the following three
DataRow methods:

GetParentRow
GetParentRows
GetChildRows

I'm guessing the difference between the first two is that one returns an
array while the other returns a single Row, which leads me to wonder, what
would happen if this option were used but there were more than one parent
row. On that note, in a relationship, what defines one row as a parent and
one as a child? Is it that multiple child fields can refer to a single
parent
field and from this, the engine somehow deduces which side is the child
and
which is the parent? From what I see above, it's possible for a table to
have
multiple parents. How would this work? When you create a relation between
tables in a dataset, if you don't specify which side is which, what rules
are
used to decide?

Thanks...

Jul 21 '05 #2

P: n/a
Thanks for your reply, Jay. I think I'll grab a copy of that book. From what
I see, this is the definition of the "add" method for adding a new
datarelation:

Creates a DataRelation with a specified parent and child column, and adds it
to the collection.

Supported by the .NET Compact Framework.

[Visual Basic] Overloads Public Overridable Function Add(DataColumn,
DataColumn) As DataRelation
[C#] public virtual DataRelation Add(DataColumn, DataColumn);

It looks like the first column passed in will serve as the parent and the
second will serve as the child. Is this accurate? If so, does it make a
difference which one will be parent and which will be child? I was under the
impression that the child references data in the parent, but I could be
mistaken. I don't see why it should matter if you use GetChildRows or
GetParentRows becausefi you've got a starting point (a datarow) and a
direction to go in (a datarelation), there's really no ambiguity, so why do
you have to chose between these two choices?

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
The parent & child is defined when you define the DataRelation object either
in code or via an XSD.

All three functions expect a DataRelation (either name or actual object) to
determine which relationship to resolve.

For a complete explanation of advanced features of Datasets, such as parent
rows & child rows, I would strongly recommend you read David Sceppa's book
"Microsoft ADO.NET - Core Reference" from MS Press. As it is a good tutorial
on ADO.NET as well as a good desk reference once you know ADO.NET.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:C1**********************************@microsof t.com...
Could someone fill me in on the difference between the following three
DataRow methods:

GetParentRow
GetParentRows
GetChildRows

I'm guessing the difference between the first two is that one returns an
array while the other returns a single Row, which leads me to wonder, what
would happen if this option were used but there were more than one parent
row. On that note, in a relationship, what defines one row as a parent and
one as a child? Is it that multiple child fields can refer to a single
parent
field and from this, the engine somehow deduces which side is the child
and
which is the parent? From what I see above, it's possible for a table to
have
multiple parents. How would this work? When you create a relation between
tables in a dataset, if you don't specify which side is which, what rules
are
used to decide?

Thanks...


Jul 21 '05 #3

P: n/a
Ben,
For a 1 to Many relationship it definitely makes a difference.

Consider you have 2 tables: Orders & Order Details.

Which table would you expect to be the Parent?

Which table would you expect to be the Child?
For a Many to Many relationship it physically doesn't make a difference,
however it may logically make a difference.

The following thread has an example of creating 2 tables that have a Many to
Many relationship & use of GetParentRows. Hopefully there is enough there to
give you ideas...

http://groups-beta.google.com/group/...2f4a68079a57a8

If the link is broke, search groups.google.com for "Adding a column to a
dataset" from about 24 June 2004 in the microsoft.public.dotnet.languages.vb
newsgroup.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:B3**********************************@microsof t.com...
Thanks for your reply, Jay. I think I'll grab a copy of that book. From
what
I see, this is the definition of the "add" method for adding a new
datarelation:

Creates a DataRelation with a specified parent and child column, and adds
it
to the collection.

Supported by the .NET Compact Framework.

[Visual Basic] Overloads Public Overridable Function Add(DataColumn,
DataColumn) As DataRelation
[C#] public virtual DataRelation Add(DataColumn, DataColumn);

It looks like the first column passed in will serve as the parent and the
second will serve as the child. Is this accurate? If so, does it make a
difference which one will be parent and which will be child? I was under
the
impression that the child references data in the parent, but I could be
mistaken. I don't see why it should matter if you use GetChildRows or
GetParentRows becausefi you've got a starting point (a datarow) and a
direction to go in (a datarelation), there's really no ambiguity, so why
do
you have to chose between these two choices?

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
The parent & child is defined when you define the DataRelation object
either
in code or via an XSD.

All three functions expect a DataRelation (either name or actual object)
to
determine which relationship to resolve.

For a complete explanation of advanced features of Datasets, such as
parent
rows & child rows, I would strongly recommend you read David Sceppa's
book
"Microsoft ADO.NET - Core Reference" from MS Press. As it is a good
tutorial
on ADO.NET as well as a good desk reference once you know ADO.NET.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:C1**********************************@microsof t.com...
> Could someone fill me in on the difference between the following three
> DataRow methods:
>
> GetParentRow
> GetParentRows
> GetChildRows
>
> I'm guessing the difference between the first two is that one returns
> an
> array while the other returns a single Row, which leads me to wonder,
> what
> would happen if this option were used but there were more than one
> parent
> row. On that note, in a relationship, what defines one row as a parent
> and
> one as a child? Is it that multiple child fields can refer to a single
> parent
> field and from this, the engine somehow deduces which side is the child
> and
> which is the parent? From what I see above, it's possible for a table
> to
> have
> multiple parents. How would this work? When you create a relation
> between
> tables in a dataset, if you don't specify which side is which, what
> rules
> are
> used to decide?
>
> Thanks...


Jul 21 '05 #4

P: n/a
Hi Jay,

From the two examples you gave me, the one-to-many example is probably more
straightforward, so I'll focus on that. In a customers / orders example, it's
intuitively clear to me that in a relationship between the two, the customers
table is the parent and the orders table is the child. To me, I assume this
because for one customer, there can be multiple orders. I've been looking for
a formal definition of the two, but unsuccessfully. I guess what I'm trying
to gather is, in this circumstance, when you create and add the relationship
between customers and orders, does the add method assume that the first
column parameter will be the parent and the second will be the child? Is
there something within the relationship to mark the two tables, one as parent
and one as child, or is it more of an intrinsic quality that is merely
implied based on the circumstance (one to many, in this case)? Otherwise,
might you decide which table fills which role and get behavioural
differences? I subscribe to books24x7 and was looking through the book you
recommended. There's some good stuff, but not too much on comparing the
GetChildRows and GetParentRows methods. Thanks for the Clarification, Jay...

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
For a 1 to Many relationship it definitely makes a difference.

Consider you have 2 tables: Orders & Order Details.

Which table would you expect to be the Parent?

Which table would you expect to be the Child?
For a Many to Many relationship it physically doesn't make a difference,
however it may logically make a difference.

The following thread has an example of creating 2 tables that have a Many to
Many relationship & use of GetParentRows. Hopefully there is enough there to
give you ideas...

http://groups-beta.google.com/group/...2f4a68079a57a8

If the link is broke, search groups.google.com for "Adding a column to a
dataset" from about 24 June 2004 in the microsoft.public.dotnet.languages.vb
newsgroup.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:B3**********************************@microsof t.com...
Thanks for your reply, Jay. I think I'll grab a copy of that book. From
what
I see, this is the definition of the "add" method for adding a new
datarelation:

Creates a DataRelation with a specified parent and child column, and adds
it
to the collection.

Supported by the .NET Compact Framework.

[Visual Basic] Overloads Public Overridable Function Add(DataColumn,
DataColumn) As DataRelation
[C#] public virtual DataRelation Add(DataColumn, DataColumn);

It looks like the first column passed in will serve as the parent and the
second will serve as the child. Is this accurate? If so, does it make a
difference which one will be parent and which will be child? I was under
the
impression that the child references data in the parent, but I could be
mistaken. I don't see why it should matter if you use GetChildRows or
GetParentRows becausefi you've got a starting point (a datarow) and a
direction to go in (a datarelation), there's really no ambiguity, so why
do
you have to chose between these two choices?

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
The parent & child is defined when you define the DataRelation object
either
in code or via an XSD.

All three functions expect a DataRelation (either name or actual object)
to
determine which relationship to resolve.

For a complete explanation of advanced features of Datasets, such as
parent
rows & child rows, I would strongly recommend you read David Sceppa's
book
"Microsoft ADO.NET - Core Reference" from MS Press. As it is a good
tutorial
on ADO.NET as well as a good desk reference once you know ADO.NET.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:C1**********************************@microsof t.com...
> Could someone fill me in on the difference between the following three
> DataRow methods:
>
> GetParentRow
> GetParentRows
> GetChildRows
>
> I'm guessing the difference between the first two is that one returns
> an
> array while the other returns a single Row, which leads me to wonder,
> what
> would happen if this option were used but there were more than one
> parent
> row. On that note, in a relationship, what defines one row as a parent
> and
> one as a child? Is it that multiple child fields can refer to a single
> parent
> field and from this, the engine somehow deduces which side is the child
> and
> which is the parent? From what I see above, it's possible for a table
> to
> have
> multiple parents. How would this work? When you create a relation
> between
> tables in a dataset, if you don't specify which side is which, what
> rules
> are
> used to decide?
>
> Thanks...


Jul 21 '05 #5

P: n/a
Ben,
does the add method assume that the first
column parameter will be the parent and the second will be the child? Why would it assume anything??? Did you read the documentation itself???

http://msdn.microsoft.com/library/de...sAddTopic2.asp

[Visual Basic]
Overloads Public Overridable Function Add( _
ByVal parentColumn As DataColumn, _
ByVal childColumn As DataColumn _
) As DataRelation
[C#]
public virtual DataRelation Add(
DataColumn parentColumn,
DataColumn childColumn
);

The first column *IS* the parent, the second *IS* the child... I'm really
not sure what you are reading that does not include the names of the
parameters, the names of the parameters clearly indicate which is the parent
& which is the child!

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com... Hi Jay,

From the two examples you gave me, the one-to-many example is probably
more
straightforward, so I'll focus on that. In a customers / orders example,
it's
intuitively clear to me that in a relationship between the two, the
customers
table is the parent and the orders table is the child. To me, I assume
this
because for one customer, there can be multiple orders. I've been looking
for
a formal definition of the two, but unsuccessfully. I guess what I'm
trying
to gather is, in this circumstance, when you create and add the
relationship
between customers and orders, does the add method assume that the first
column parameter will be the parent and the second will be the child? Is
there something within the relationship to mark the two tables, one as
parent
and one as child, or is it more of an intrinsic quality that is merely
implied based on the circumstance (one to many, in this case)? Otherwise,
might you decide which table fills which role and get behavioural
differences? I subscribe to books24x7 and was looking through the book you
recommended. There's some good stuff, but not too much on comparing the
GetChildRows and GetParentRows methods. Thanks for the Clarification,
Jay...

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
For a 1 to Many relationship it definitely makes a difference.

Consider you have 2 tables: Orders & Order Details.

Which table would you expect to be the Parent?

Which table would you expect to be the Child?
For a Many to Many relationship it physically doesn't make a difference,
however it may logically make a difference.

The following thread has an example of creating 2 tables that have a Many
to
Many relationship & use of GetParentRows. Hopefully there is enough there
to
give you ideas...

http://groups-beta.google.com/group/...2f4a68079a57a8

If the link is broke, search groups.google.com for "Adding a column to a
dataset" from about 24 June 2004 in the
microsoft.public.dotnet.languages.vb
newsgroup.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:B3**********************************@microsof t.com...
> Thanks for your reply, Jay. I think I'll grab a copy of that book. From
> what
> I see, this is the definition of the "add" method for adding a new
> datarelation:
>
> Creates a DataRelation with a specified parent and child column, and
> adds
> it
> to the collection.
>
> Supported by the .NET Compact Framework.
>
> [Visual Basic] Overloads Public Overridable Function Add(DataColumn,
> DataColumn) As DataRelation
> [C#] public virtual DataRelation Add(DataColumn, DataColumn);
>
> It looks like the first column passed in will serve as the parent and
> the
> second will serve as the child. Is this accurate? If so, does it make a
> difference which one will be parent and which will be child? I was
> under
> the
> impression that the child references data in the parent, but I could be
> mistaken. I don't see why it should matter if you use GetChildRows or
> GetParentRows becausefi you've got a starting point (a datarow) and a
> direction to go in (a datarelation), there's really no ambiguity, so
> why
> do
> you have to chose between these two choices?
>
> -Ben
>
> "Jay B. Harlow [MVP - Outlook]" wrote:
>
>> Ben,
>> The parent & child is defined when you define the DataRelation object
>> either
>> in code or via an XSD.
>>
>> All three functions expect a DataRelation (either name or actual
>> object)
>> to
>> determine which relationship to resolve.
>>
>> For a complete explanation of advanced features of Datasets, such as
>> parent
>> rows & child rows, I would strongly recommend you read David Sceppa's
>> book
>> "Microsoft ADO.NET - Core Reference" from MS Press. As it is a good
>> tutorial
>> on ADO.NET as well as a good desk reference once you know ADO.NET.
>>
>> Hope this helps
>> Jay
>>
>> "Ben R." <Be**@discussions.microsoft.com> wrote in message
>> news:C1**********************************@microsof t.com...
>> > Could someone fill me in on the difference between the following
>> > three
>> > DataRow methods:
>> >
>> > GetParentRow
>> > GetParentRows
>> > GetChildRows
>> >
>> > I'm guessing the difference between the first two is that one
>> > returns
>> > an
>> > array while the other returns a single Row, which leads me to
>> > wonder,
>> > what
>> > would happen if this option were used but there were more than one
>> > parent
>> > row. On that note, in a relationship, what defines one row as a
>> > parent
>> > and
>> > one as a child? Is it that multiple child fields can refer to a
>> > single
>> > parent
>> > field and from this, the engine somehow deduces which side is the
>> > child
>> > and
>> > which is the parent? From what I see above, it's possible for a
>> > table
>> > to
>> > have
>> > multiple parents. How would this work? When you create a relation
>> > between
>> > tables in a dataset, if you don't specify which side is which, what
>> > rules
>> > are
>> > used to decide?
>> >
>> > Thanks...
>>
>>
>>


Jul 21 '05 #6

P: n/a
Sorry about that, Jay. I was looking at the overload list. Thanks for your
help...

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
does the add method assume that the first
column parameter will be the parent and the second will be the child?

Why would it assume anything??? Did you read the documentation itself???

http://msdn.microsoft.com/library/de...sAddTopic2.asp

[Visual Basic]
Overloads Public Overridable Function Add( _
ByVal parentColumn As DataColumn, _
ByVal childColumn As DataColumn _
) As DataRelation
[C#]
public virtual DataRelation Add(
DataColumn parentColumn,
DataColumn childColumn
);

The first column *IS* the parent, the second *IS* the child... I'm really
not sure what you are reading that does not include the names of the
parameters, the names of the parameters clearly indicate which is the parent
& which is the child!

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...
Hi Jay,

From the two examples you gave me, the one-to-many example is probably
more
straightforward, so I'll focus on that. In a customers / orders example,
it's
intuitively clear to me that in a relationship between the two, the
customers
table is the parent and the orders table is the child. To me, I assume
this
because for one customer, there can be multiple orders. I've been looking
for
a formal definition of the two, but unsuccessfully. I guess what I'm
trying
to gather is, in this circumstance, when you create and add the
relationship
between customers and orders, does the add method assume that the first
column parameter will be the parent and the second will be the child? Is
there something within the relationship to mark the two tables, one as
parent
and one as child, or is it more of an intrinsic quality that is merely
implied based on the circumstance (one to many, in this case)? Otherwise,
might you decide which table fills which role and get behavioural
differences? I subscribe to books24x7 and was looking through the book you
recommended. There's some good stuff, but not too much on comparing the
GetChildRows and GetParentRows methods. Thanks for the Clarification,
Jay...

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
For a 1 to Many relationship it definitely makes a difference.

Consider you have 2 tables: Orders & Order Details.

Which table would you expect to be the Parent?

Which table would you expect to be the Child?
For a Many to Many relationship it physically doesn't make a difference,
however it may logically make a difference.

The following thread has an example of creating 2 tables that have a Many
to
Many relationship & use of GetParentRows. Hopefully there is enough there
to
give you ideas...

http://groups-beta.google.com/group/...2f4a68079a57a8

If the link is broke, search groups.google.com for "Adding a column to a
dataset" from about 24 June 2004 in the
microsoft.public.dotnet.languages.vb
newsgroup.

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:B3**********************************@microsof t.com...
> Thanks for your reply, Jay. I think I'll grab a copy of that book. From
> what
> I see, this is the definition of the "add" method for adding a new
> datarelation:
>
> Creates a DataRelation with a specified parent and child column, and
> adds
> it
> to the collection.
>
> Supported by the .NET Compact Framework.
>
> [Visual Basic] Overloads Public Overridable Function Add(DataColumn,
> DataColumn) As DataRelation
> [C#] public virtual DataRelation Add(DataColumn, DataColumn);
>
> It looks like the first column passed in will serve as the parent and
> the
> second will serve as the child. Is this accurate? If so, does it make a
> difference which one will be parent and which will be child? I was
> under
> the
> impression that the child references data in the parent, but I could be
> mistaken. I don't see why it should matter if you use GetChildRows or
> GetParentRows becausefi you've got a starting point (a datarow) and a
> direction to go in (a datarelation), there's really no ambiguity, so
> why
> do
> you have to chose between these two choices?
>
> -Ben
>
> "Jay B. Harlow [MVP - Outlook]" wrote:
>
>> Ben,
>> The parent & child is defined when you define the DataRelation object
>> either
>> in code or via an XSD.
>>
>> All three functions expect a DataRelation (either name or actual
>> object)
>> to
>> determine which relationship to resolve.
>>
>> For a complete explanation of advanced features of Datasets, such as
>> parent
>> rows & child rows, I would strongly recommend you read David Sceppa's
>> book
>> "Microsoft ADO.NET - Core Reference" from MS Press. As it is a good
>> tutorial
>> on ADO.NET as well as a good desk reference once you know ADO.NET.
>>
>> Hope this helps
>> Jay
>>
>> "Ben R." <Be**@discussions.microsoft.com> wrote in message
>> news:C1**********************************@microsof t.com...
>> > Could someone fill me in on the difference between the following
>> > three
>> > DataRow methods:
>> >
>> > GetParentRow
>> > GetParentRows
>> > GetChildRows
>> >
>> > I'm guessing the difference between the first two is that one
>> > returns
>> > an
>> > array while the other returns a single Row, which leads me to
>> > wonder,
>> > what
>> > would happen if this option were used but there were more than one
>> > parent
>> > row. On that note, in a relationship, what defines one row as a
>> > parent
>> > and
>> > one as a child? Is it that multiple child fields can refer to a
>> > single
>> > parent
>> > field and from this, the engine somehow deduces which side is the
>> > child
>> > and
>> > which is the parent? From what I see above, it's possible for a
>> > table
>> > to
>> > have
>> > multiple parents. How would this work? When you create a relation
>> > between
>> > tables in a dataset, if you don't specify which side is which, what
>> > rules
>> > are
>> > used to decide?
>> >
>> > Thanks...
>>
>>
>>


Jul 21 '05 #7

P: n/a
Ben,
No problem.

Unfortunately the overload list is too high of detail, you need to "zoom" in
to each specific function for the actual details...

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:57**********************************@microsof t.com...
Sorry about that, Jay. I was looking at the overload list. Thanks for your
help...

-Ben

"Jay B. Harlow [MVP - Outlook]" wrote:
Ben,
> does the add method assume that the first
> column parameter will be the parent and the second will be the child?

Why would it assume anything??? Did you read the documentation itself???

http://msdn.microsoft.com/library/de...sAddTopic2.asp

[Visual Basic]
Overloads Public Overridable Function Add( _
ByVal parentColumn As DataColumn, _
ByVal childColumn As DataColumn _
) As DataRelation
[C#]
public virtual DataRelation Add(
DataColumn parentColumn,
DataColumn childColumn
);

The first column *IS* the parent, the second *IS* the child... I'm really
not sure what you are reading that does not include the names of the
parameters, the names of the parameters clearly indicate which is the
parent
& which is the child!

Hope this helps
Jay

"Ben R." <Be**@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...
> Hi Jay,
>
> From the two examples you gave me, the one-to-many example is probably
> more
> straightforward, so I'll focus on that. In a customers / orders
> example,
> it's
> intuitively clear to me that in a relationship between the two, the
> customers
> table is the parent and the orders table is the child. To me, I assume
> this
> because for one customer, there can be multiple orders. I've been
> looking
> for
> a formal definition of the two, but unsuccessfully. I guess what I'm
> trying
> to gather is, in this circumstance, when you create and add the
> relationship
> between customers and orders, does the add method assume that the first
> column parameter will be the parent and the second will be the child?
> Is
> there something within the relationship to mark the two tables, one as
> parent
> and one as child, or is it more of an intrinsic quality that is merely
> implied based on the circumstance (one to many, in this case)?
> Otherwise,
> might you decide which table fills which role and get behavioural
> differences? I subscribe to books24x7 and was looking through the book
> you
> recommended. There's some good stuff, but not too much on comparing the
> GetChildRows and GetParentRows methods. Thanks for the Clarification,
> Jay...
>
> -Ben
>
> "Jay B. Harlow [MVP - Outlook]" wrote:
>
>> Ben,
>> For a 1 to Many relationship it definitely makes a difference.
>>
>> Consider you have 2 tables: Orders & Order Details.
>>
>> Which table would you expect to be the Parent?
>>
>> Which table would you expect to be the Child?
>>
>>
>> For a Many to Many relationship it physically doesn't make a
>> difference,
>> however it may logically make a difference.
>>
>> The following thread has an example of creating 2 tables that have a
>> Many
>> to
>> Many relationship & use of GetParentRows. Hopefully there is enough
>> there
>> to
>> give you ideas...
>>
>> http://groups-beta.google.com/group/...2f4a68079a57a8
>>
>> If the link is broke, search groups.google.com for "Adding a column to
>> a
>> dataset" from about 24 June 2004 in the
>> microsoft.public.dotnet.languages.vb
>> newsgroup.
>>
>> Hope this helps
>> Jay
>>
>> "Ben R." <Be**@discussions.microsoft.com> wrote in message
>> news:B3**********************************@microsof t.com...
>> > Thanks for your reply, Jay. I think I'll grab a copy of that book.
>> > From
>> > what
>> > I see, this is the definition of the "add" method for adding a new
>> > datarelation:
>> >
>> > Creates a DataRelation with a specified parent and child column, and
>> > adds
>> > it
>> > to the collection.
>> >
>> > Supported by the .NET Compact Framework.
>> >
>> > [Visual Basic] Overloads Public Overridable Function Add(DataColumn,
>> > DataColumn) As DataRelation
>> > [C#] public virtual DataRelation Add(DataColumn, DataColumn);
>> >
>> > It looks like the first column passed in will serve as the parent
>> > and
>> > the
>> > second will serve as the child. Is this accurate? If so, does it
>> > make a
>> > difference which one will be parent and which will be child? I was
>> > under
>> > the
>> > impression that the child references data in the parent, but I could
>> > be
>> > mistaken. I don't see why it should matter if you use GetChildRows
>> > or
>> > GetParentRows becausefi you've got a starting point (a datarow) and
>> > a
>> > direction to go in (a datarelation), there's really no ambiguity, so
>> > why
>> > do
>> > you have to chose between these two choices?
>> >
>> > -Ben
>> >
>> > "Jay B. Harlow [MVP - Outlook]" wrote:
>> >
>> >> Ben,
>> >> The parent & child is defined when you define the DataRelation
>> >> object
>> >> either
>> >> in code or via an XSD.
>> >>
>> >> All three functions expect a DataRelation (either name or actual
>> >> object)
>> >> to
>> >> determine which relationship to resolve.
>> >>
>> >> For a complete explanation of advanced features of Datasets, such
>> >> as
>> >> parent
>> >> rows & child rows, I would strongly recommend you read David
>> >> Sceppa's
>> >> book
>> >> "Microsoft ADO.NET - Core Reference" from MS Press. As it is a good
>> >> tutorial
>> >> on ADO.NET as well as a good desk reference once you know ADO.NET.
>> >>
>> >> Hope this helps
>> >> Jay
>> >>
>> >> "Ben R." <Be**@discussions.microsoft.com> wrote in message
>> >> news:C1**********************************@microsof t.com...
>> >> > Could someone fill me in on the difference between the following
>> >> > three
>> >> > DataRow methods:
>> >> >
>> >> > GetParentRow
>> >> > GetParentRows
>> >> > GetChildRows
>> >> >
>> >> > I'm guessing the difference between the first two is that one
>> >> > returns
>> >> > an
>> >> > array while the other returns a single Row, which leads me to
>> >> > wonder,
>> >> > what
>> >> > would happen if this option were used but there were more than
>> >> > one
>> >> > parent
>> >> > row. On that note, in a relationship, what defines one row as a
>> >> > parent
>> >> > and
>> >> > one as a child? Is it that multiple child fields can refer to a
>> >> > single
>> >> > parent
>> >> > field and from this, the engine somehow deduces which side is the
>> >> > child
>> >> > and
>> >> > which is the parent? From what I see above, it's possible for a
>> >> > table
>> >> > to
>> >> > have
>> >> > multiple parents. How would this work? When you create a relation
>> >> > between
>> >> > tables in a dataset, if you don't specify which side is which,
>> >> > what
>> >> > rules
>> >> > are
>> >> > used to decide?
>> >> >
>> >> > Thanks...
>> >>
>> >>
>> >>
>>
>>
>>


Jul 21 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.