C
Cip
Two things which seem like I cannot do with .NET:
1) Can I copy a DataColumn (WITH VALUES) from one table to another
brand new table? It seems like the only way to do this is to copy the
entire table (via Copy()), then remove the columns I dont need.
Terrible.
If i try this:
Dim newTbl as new DataTable("NewTable")
newTbl.Columns.add(SourceTable.Columns(0))
It blows up since 2 columns cant be in the same dataset. Instead of
adding the new column by Object Reference, can I not make a brand new
copy of the column object and add it to the new Table by value??
How come there isnt a DataColumn.copy() method ?? IMHO there seems to
be no consistency with the ADO Objects. Not all of them have Clone()
or Copy(). A good design should have consistency between objects with
a similar purpose (in this case as types of Data Containers)... am i
missing something?
Can someone from MS please tell me how to do this WITHOUT manually
looping to populate data?
If it cannot be done then I guess I will just have to keep my existing
workaround. Just wanted to make sure I wasnt misunderstanding
anything.
2) Copying a Child DataTable.
If I have a child DataTable with various column expressions (like
"Parent(myRelation).Col1+Col1"), then I am unable to copy() the table.
I get the runtime exception "cannot find relation 0"
This is definitely a bug, and not a 'feature' of ADO.NET. With a good
design any DataTable object should be able to invoke its copy() method
w/o runtime exceptions. All of its relations should be taken care
"under-the-hood" when I call copy().
In MSDN there are no preconditions for the copy() method stating that
"only non-child table instances can call copy()"
Final Comments:
I apologize for being to critical, but I have spent several weeks
trying to piece together a *simple* reporting application using .NET
without much success. Every solution I seem to come up with is
slammed by some type of MS limitation, which is a combination of me
not fully comprehending System.Data's classes and, in my opinion,
buggy classes.
Keeping in mind that I am developing applications in a Connected
Environment, ADO.NET is a small step (but a step nonetheless) from ADO
2.whatever-the-last was (2.6? 2.5?)
The new DataSet class is great for disconnected environments, but in
my case I still have to resort to manually looping through columns,
row-by-row, to perform calculations. I have found several
bugs/limitations to the DataSet objects on MSDN. For starters, I
cannot JOIN two tables together in a view, Updating a child table
produces an error, I cannot copy a child table using copy(), I cannot
simply copy a column from one table to another, etc.
Can someone agree/disagree to this?
Can someone help me with the two problems i have?
thank you very much for your time, and thanks to those who take their
time to reply to this message.
1) Can I copy a DataColumn (WITH VALUES) from one table to another
brand new table? It seems like the only way to do this is to copy the
entire table (via Copy()), then remove the columns I dont need.
Terrible.
If i try this:
Dim newTbl as new DataTable("NewTable")
newTbl.Columns.add(SourceTable.Columns(0))
It blows up since 2 columns cant be in the same dataset. Instead of
adding the new column by Object Reference, can I not make a brand new
copy of the column object and add it to the new Table by value??
How come there isnt a DataColumn.copy() method ?? IMHO there seems to
be no consistency with the ADO Objects. Not all of them have Clone()
or Copy(). A good design should have consistency between objects with
a similar purpose (in this case as types of Data Containers)... am i
missing something?
Can someone from MS please tell me how to do this WITHOUT manually
looping to populate data?
If it cannot be done then I guess I will just have to keep my existing
workaround. Just wanted to make sure I wasnt misunderstanding
anything.
2) Copying a Child DataTable.
If I have a child DataTable with various column expressions (like
"Parent(myRelation).Col1+Col1"), then I am unable to copy() the table.
I get the runtime exception "cannot find relation 0"
This is definitely a bug, and not a 'feature' of ADO.NET. With a good
design any DataTable object should be able to invoke its copy() method
w/o runtime exceptions. All of its relations should be taken care
"under-the-hood" when I call copy().
In MSDN there are no preconditions for the copy() method stating that
"only non-child table instances can call copy()"
Final Comments:
I apologize for being to critical, but I have spent several weeks
trying to piece together a *simple* reporting application using .NET
without much success. Every solution I seem to come up with is
slammed by some type of MS limitation, which is a combination of me
not fully comprehending System.Data's classes and, in my opinion,
buggy classes.
Keeping in mind that I am developing applications in a Connected
Environment, ADO.NET is a small step (but a step nonetheless) from ADO
2.whatever-the-last was (2.6? 2.5?)
The new DataSet class is great for disconnected environments, but in
my case I still have to resort to manually looping through columns,
row-by-row, to perform calculations. I have found several
bugs/limitations to the DataSet objects on MSDN. For starters, I
cannot JOIN two tables together in a view, Updating a child table
produces an error, I cannot copy a child table using copy(), I cannot
simply copy a column from one table to another, etc.
Can someone agree/disagree to this?
Can someone help me with the two problems i have?
thank you very much for your time, and thanks to those who take their
time to reply to this message.