Subclassing DataRelation and Cloning

S

Shawn Cannon

I have a subclassed DataSet that also subclasses DataTable, DataRow,
DataColumn and DataRelation. When the DataSet is cloned the DataTable,
DataRow and DataColumn objects are cloned as their respective subclassed
types, however the DataRelation objects are cloned as
System.Data.DataRelation types. I have tried working around this by
overriding DataSet.Clone and removing and then readding the relationships
using the proper type. Is this by design, an oversight or am I missing
something?

Thanks,
Shawn
 
K

Kevin Yu [MSFT]

Hi Shawn,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to know why the DataRelation
in the DataSet was not cloned as subclass types. If there is any
misunderstanding, please feel free to let me know.

Could you let me know how you created the subclasses? Are they generated by
VS.NET for a typed DataSet?

It is by design that DataSet.Clone will clone all structure of the DataSet,
including all DataTable schemas, relations, and constraints. The typed
DataSet Clone override this method to cast the DataTables to subclass
types. However, this operation was not done with DataRelations, which is by
design.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
S

Shawn Cannon

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to know why the DataRelation
in the DataSet was not cloned as subclass types.

Yes. That is the problem.
Could you let me know how you created the subclasses? Are they generated
by
VS.NET for a typed DataSet?

It is NOT a VS typed DataSet. I have simply created my own data relation
class that inherits from System.Data.DataRelation.

The documentation for DataSet.Clone states that it:

"Copies the structure of the DataSet, including all DataTable schemas,
relations, and constraints. Does not copy any data."

And in the Remarks section it states:

"Note If these classes have been subclassed, the clone will also be of the
same subclasses."

The documentation is not consistent with the behavior. The following sample
illustrates the problem:


using System.Diagnostics;
using System.Data;

namespace DataRelationCloneBug
{
public class MyDataSet : System.Data.DataSet
{
public MyDataSet()
{
}
}

public class MyDataTable : System.Data.DataTable
{
public MyDataTable()
{
}
}

public class MyDataRelation : System.Data.DataRelation
{
public MyDataRelation( string relationName, DataColumn parentColumn,
DataColumn childColumn)
: base( relationName, parentColumn, childColumn )
{
}
}

public class Program
{
[System.STAThread]
static void Main()
{
MyDataSet DataSet1 = new MyDataSet();

MyDataTable Table1 = new MyDataTable();
Table1.TableName = "Table1";
Table1.Columns.Add("PK");
DataSet1.Tables.Add( Table1 );

MyDataTable Table2 = new MyDataTable();
Table2.TableName = "Table2";
Table2.Columns.Add( "FK" );
DataSet1.Tables.Add( Table2 );

DataSet1.Relations.Add( new MyDataRelation( "Relation1",
Table1.Columns["PK"], Table2.Columns["FK"]) );

MyDataSet DataSet2 = DataSet1.Clone() as MyDataSet;

Trace.Write( "The cloned data set is of type " );
Trace.Write( DataSet2.GetType().Name );
Trace.Write( " and Table1 is of type " );
Trace.Write( DataSet2.Tables["Table1"].GetType().Name );
Trace.Write( ", but Relation1 is of type " );
Trace.Write( DataSet2.Relations["Relation1"].GetType().Name );
Trace.WriteLine( "." );
}
}
}
 
K

Kevin Yu [MSFT]

Hi Shawn,

Currently, I'm contacting the product team to confirm this issue, and will
update you as soon as they give me any response.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
M

[MSFT]

Hello Shawn,

Currently this is a limitation in DataSet. Returning typed/ derived type
objects mainly was for typed dataset and it makes sense to return
typedDataSet , typedDataTable and typedDataRow; but while designing, it
did not make much sense to return "typed" DataRelation, ¡°typed¡±
UniqueConstraint or ¡°typed¡° ForeignKeyConstraint.

I agree that it is inconsistent story and it would be nice to have the same
behavior. Currently, our DEE team is discussing to change the behavior in
future release.

Please let me know if you have any other question

Thanks

Luke
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top