J
James
I have an ASP.Net database webapp running on .Net 1.1 and I have
unfortunately built into it a lot of code making use of Relations and
expression-type DataColumns containing .Parent and .Child references.
Now it has got moderately complex I am running into huge problems with
this aspect of the application.
After searching the newsgroups I find there was a problem with updating
or adding data to DataTables containing expression columns referring to
other DataTables via Relations a long time ago. I have found a couple
of KB hotfixes dealing with these problems but apparently they aren't
fully tested so I daren't use the one I have been supplied with because
my hosting company may be unwilling to apply it to their version of the
framework. I find that I get VersionNotFoundExceptions which come and
go quite unpredictably according to whether I do things through the
DefaultView of the table or act directly on the table, and whether I
make changes to the parent table before the child or vice versa.
The last straw has been that I have found adding new rows to a
DataTable has caused two new rows in the DefaultView for each row
added.
Looking more in the newsgroups there are many different kinds of
problems reported with this area of ADO.Net and it appears these
problems are not resolved in .Net 2.0.
It would be nice to know anyone's thoughts and what Microsoft intend to
do about this part of ADO.Net being effectively unusable (in my
opinion).
What would be a very useful replacement for this functionality would be
to provide a type of column that could use client code to generate
values for that column probably via an event handler (something like
OnValueRequested) which would call the client code whenever some other
code needed to know the value of that column on a given row.
It would also be a very good idea if it was widely advertised that this
functionality is not in any way reliable so people writing extensive
projects didn't mistakenly try to make use of it.
In the meantime I am going to have to spend more time (and therefore
money) on this project writing custom code to handle retrieving values
in related rows.
James
unfortunately built into it a lot of code making use of Relations and
expression-type DataColumns containing .Parent and .Child references.
Now it has got moderately complex I am running into huge problems with
this aspect of the application.
After searching the newsgroups I find there was a problem with updating
or adding data to DataTables containing expression columns referring to
other DataTables via Relations a long time ago. I have found a couple
of KB hotfixes dealing with these problems but apparently they aren't
fully tested so I daren't use the one I have been supplied with because
my hosting company may be unwilling to apply it to their version of the
framework. I find that I get VersionNotFoundExceptions which come and
go quite unpredictably according to whether I do things through the
DefaultView of the table or act directly on the table, and whether I
make changes to the parent table before the child or vice versa.
The last straw has been that I have found adding new rows to a
DataTable has caused two new rows in the DefaultView for each row
added.
Looking more in the newsgroups there are many different kinds of
problems reported with this area of ADO.Net and it appears these
problems are not resolved in .Net 2.0.
It would be nice to know anyone's thoughts and what Microsoft intend to
do about this part of ADO.Net being effectively unusable (in my
opinion).
What would be a very useful replacement for this functionality would be
to provide a type of column that could use client code to generate
values for that column probably via an event handler (something like
OnValueRequested) which would call the client code whenever some other
code needed to know the value of that column on a given row.
It would also be a very good idea if it was widely advertised that this
functionality is not in any way reliable so people writing extensive
projects didn't mistakenly try to make use of it.
In the meantime I am going to have to spend more time (and therefore
money) on this project writing custom code to handle retrieving values
in related rows.
James