MS Access validation rules -- how to handle updates to datatable

[Jeremy]

I have a vb .net 2003 app that uses access 2k as a backend. The main table
has some validation rules (legacy stuff brought forward inadvertantly, and
now we're stuck with 'em).

The problem is, I do a dataadaptor.update, and an exception is thrown. I
would prefer to validate before the update & tell the user to fix the data.
dataset.hasErrors does not detect the validation violation.

When the exception is thrown I can of course catch it, but the datarow is
somehow lost. Maybe if I knew what was happening here, I could recover the
row & let the user deal with it, but I haven't found the answer yet.

Help greatly appreciated!

Jeremy

 

[Jeremy]

One little factoid: After an update attempt that fails due to validation
rule, the user corrects the data, attempts to save again, and now the
hasErrors property is True. Obviously left over from the previous attempt
to save.

How do I resolve this?

Jeremy

 

[Cor Ligthert]

Jeremy,

Did you know that there is a rollback?

http://msdn.microsoft.com/library/d...taoledboledbtransactionclassrollbacktopic.asp

I hope this helps?

Cor

 

[Jeremy]

Cor, I do understand transactions, but am not sure this is a solution to my
issue. The update is failing, and therefore there is nothing to rollback,
since nothing posted to start with.

My understanding of hasError is sketchy. Apparently, the update fails, sets
rowError (and therefore hasError). I send the data back to the user to
correct. They correct it, but the rowError is not automatically cleared.
It seems that I can set it to "" in a try/catch when the update fails. I'm
experimenting with this now.

Jeremy

 

[Cor Ligthert]

Jeremy,

My thought was that when you have catch an error (and than you know than
what), to do a rollback and than correct.

To tell you more about your problem you would at least show the update part,
because I don't know with what part of the dataset you are working.

Cor

 

[Cor Ligthert]

Jeremy.

I forgot,

Catching and resolving errors should always have the approach that they are
seldom.

Therefore here maybe some more time to solve those, while the user will
normally accept that.

Just my thought,

Cor