At 11:20 AM 3/02/2003 +0800, you wrote:

> > However, I'm really puzzled about why you want to do things this way.
>Keys
> > should not be editable. An "edit" that changes the key and sets all other
> > columns to default values isn't an edit - it's an insert. If you want a
> > new row to replace an existing row, have a sequence that inserts the new
> > row and deletes the one with the old key. That way, DefaultValues kick in
> > automatically, as designed, and the whole process is squeaky clean.
> >
>
>Hi Helen,
>
>Sorry, my mistake. Yes, it actually is an insert. The user enters an ID
>number, which is the key field, then enters the values for all the other 20
>fields or so, for that particular ID number. My concern is that after the
>user has already entered values for some of the fields then he/she decides
>to change the ID number, I would like all the other fields to reset to their
>default values, which is 0, and the user can then start anew.
>
>So do I have to write my own code then? I was actually putting it off in
>case there is a better way :)

I wouldn't allow it at all, of course...I would have a use-inaccessible
generated key which gets written into the Insert buffer via GeneratorLinks,
or on post by a BeforeInsert trigger. If you have users entering an ID
number then it's clearly because users have some influence over its content
and existence - a very strong reason *not* to use it as a key. It's a bit
like using paint to hold the pieces of a building together.

Now, getting to your situation, once the user moves off a row, or presses
the Post button, then the inserted row, as is, becomes part of the
database. If you are using Autocommit, it is committed. If it is posted
but not committed, then it is sitting in a RecVersion, waiting for a Commit.

You can get out of an Insert that is posted but not committed by calling
SysUtils.Abort as soon as the user tries to alter the ID field. To get
back to the defaults, you would need to read the new ID value before
calling Abort, and then call Insert to open another new row. That makes
your defaults available.

I wish you would rethink your design a bit, and avoid these user-entered
keys...it isn't a safe practice.

Helen