Checking for Updated Fields

If the value of field when I open a form is 'old' and the value is modified 
to 'new', but the rowset is not yet saved, then the following sets 
cMyNewValue to 'new'.
cMyNewValue = form.myrowset.fields['myfield'].value

Is there similar syntax in dBASE that is used to reference the original 
value of the field such that cMyOldValue below would be set to 'old'?
cOldValue = form.?????.fields['myfield'].????

Thanks, Clay 

Clay wrote:
> If the value of field when I open a form is 'old' and the value is 
> modified to 'new', but the rowset is not yet saved, then the following 
> sets cMyNewValue to 'new'.
> cMyNewValue = form.myrowset.fields['myfield'].value
> 
> Is there similar syntax in dBASE that is used to reference the original 
> value of the field such that cMyOldValue below would be set to 'old'?
> cOldValue = form.?????.fields['myfield'].????

You would need to trap the value before making changes. Perhaps when you 
navigate to the record, then the value could be set at that time.

Ken

-- 
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm

Thanks for the quick response, Ken. I do find it strange that the original value
for a field can't be directly accessed, though. The value is obviously stored
somewhere since abandoning the row gets back the original values for all fields
in that row.

Oh, well, it's pretty trivial to write a routine that does what you suggest. I
just didn't want to re-invent the wheel if it was already on the car.

Thanks, Clay

Ken Mayer [dBVIPS] Wrote:
> You would need to trap the value before making changes. Perhaps when you 
> navigate to the record, then the value could be set at that time.

Clay wrote:
> Thanks for the quick response, Ken. I do find it strange that the original
value for a field can't be directly accessed, though. The value is obviously
stored somewhere since abandoning the row gets back the original values for all
fields in that row.

The thing to remember is that you're working with a "buffer" or copy
of 
the record. The original data until you save, is in the original table. 
If you really need to look at it, you *could* (I don't really recommend 
it, but ...) have to copies of the table open, and when you navigate in 
one rowset, navigate in the other. The other would be a read-only (set 
autoEdit to false) rowset, which could be used to view the contents 
before the edit is saved. It might work. I don't guarantee anything, 
never tried it.


> Oh, well, it's pretty trivial to write a routine that does what you
suggest. I just didn't want to re-invent the wheel if it was already on the
car.

I understand. <g>

Ken

-- 
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm

Uh, well now I feel like like the village idiot. Of course we're working with a
buffer.

I'm planning on writing a generic routine that will create a transaction log
containing the original and current data for any modifications done to any field
on any table. I think a routine using your not recommended approach, inserted
just before the save routine that I use for all forms, will do the trick.

Thanks, Clay

Ken Mayer [dBVIPS] Wrote:

> The thing to remember is that you're working with a "buffer" or
copy of 
> the record. The original data until you save, is in the original table. 
> If you really need to look at it, you *could* (I don't really recommend 
> it, but ...) have to copies of the table open, and when you navigate in 
> one rowset, navigate in the other. The other would be a read-only (set 
> autoEdit to false) rowset, which could be used to view the contents 
> before the edit is saved. It might work. I don't guarantee anything, 
> never tried it.