Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Check for Field Changed
Mon, Nov 2 2009 2:13 PMPermanent Link

"Sean McDermott"
DBISAM latest.

This is slightly off topic but maybe someone has a better idea than what I
am suggesting. I have a table with 102 fields in a record. where field one
and field two are date and time. The other fields are grouped into 10 groups
of 10 as they are all related. In a typical layout on screen, I have 10 of
these fields grouped on a panel and there are 10 panels. The last field in
each group of 10 is a date field that is designed to show if any of the
first 9 fields have changed from one record to the next.

The data is climate related and changes are infrequent at best (copy on
append is set to true to assist). But I want to catch the lazy folks who
merely click new and post and do not make any update changes when some may
have occurred. And speaking of lazy... is there any easy way to handle this
other than checking each individual field for changes from the previous
record. The client has said any change in any of the 9 fields is good enough
to set the date so maybe ON ENTRY or on EXIT events but this won't check for
changes. Anybody had this issue or challenge before? TIA, Sean

Mon, Nov 2 2009 2:44 PMPermanent Link

"Robert"

"Sean McDermott" <Sean@HorizonCanada.com> wrote in message
news:B5C2E7FB-DD51-4195-A959-81D8E267B380@news.elevatesoft.com...
> DBISAM latest.
>
> This is slightly off topic but maybe someone has a better idea than what I
> am suggesting. I have a table with 102 fields in a record. where field one
> and field two are date and time. The other fields are grouped into 10
> groups of 10 as they are all related. In a typical layout on screen, I
> have 10 of these fields grouped on a panel and there are 10 panels. The
> last field in each group of 10 is a date field that is designed to show if
> any of the first 9 fields have changed from one record to the next.
>
> The data is climate related and changes are infrequent at best (copy on
> append is set to true to assist). But I want to catch the lazy folks who
> merely click new and post and do not make any update changes when some may
> have occurred. And speaking of lazy... is there any easy way to handle
> this other than checking each individual field for changes from the
> previous record. The client has said any change in any of the 9 fields is
> good enough to set the date so maybe ON ENTRY or on EXIT events but this
> won't check for changes. Anybody had this issue or challenge before? TIA,
> Sean
>
>

Can you just loop thru the fields in before post and compare oldvalue to
value? I don't know if oldvalue is populated when you insert a record with
copy on append, but easy enough to try.

Robert

Mon, Nov 2 2009 2:48 PMPermanent Link

"Sean McDermott"
Yup, I was going to assign old values to variables and compare to new and
assign updated date value accordingly. But, I was wondering whether there
may be an easier way. If someone looks at a field by starting to edit it
(OnEdit event), than maybe that would do the trick. We are really trying to
catch users simply clicking new and post, without any consideration for what
they are saving. If they enter the field or even start to edit it, even if
the value eventually remains the same is probably OK. Sorry for rambling,
cheers, Sean
>>
>> This is slightly off topic but maybe someone has a better idea than what
>> I am suggesting. I have a table with 102 fields in a record. where field
>> one and field two are date and time. The other fields are grouped into 10
>> groups of 10 as they are all related. In a typical layout on screen, I
>> have 10 of these fields grouped on a panel and there are 10 panels. The
>> last field in each group of 10 is a date field that is designed to show
>> if any of the first 9 fields have changed from one record to the next.
>>
>> The data is climate related and changes are infrequent at best (copy on
>> append is set to true to assist). But I want to catch the lazy folks who
>> merely click new and post and do not make any update changes when some
>> may have occurred. And speaking of lazy... is there any easy way to
>> handle this other than checking each individual field for changes from
>> the previous record. The client has said any change in any of the 9
>> fields is good enough to set the date so maybe ON ENTRY or on EXIT events
>> but this won't check for changes. Anybody had this issue or challenge
>> before? TIA, Sean
>>
>>
>
> Can you just loop thru the fields in before post and compare oldvalue to
> value? I don't know if oldvalue is populated when you insert a record with
> copy on append, but easy enough to try.
>
> Robert
>

Tue, Nov 3 2009 12:19 AMPermanent Link

Tony Bryer
In article <B5C2E7FB-DD51-4195-A959-81D8E267B380@news.elevatesoft.com>, Sean
McDermott wrote:
> The data is climate related and changes are infrequent at best (copy on
> append is set to true to assist). But I want to catch the lazy folks who
> merely click new and post and do not make any update changes when some may
> have occurred. And speaking of lazy... is there any easy way to handle this
> other than checking each individual field for changes from the previous
> record. The client has said any change in any of the 9 fields is good enough
> to set the date so maybe ON ENTRY or on EXIT events but this won't check for
> changes. Anybody had this issue or challenge before? TIA, Sean

I need to do something similar here to determine whether data changes need to
be posted across to my UK agent or vice versa. The way I do it (albeit with a
lot fewer fields) is to concatenate all the data together in one big string
and calculate a checksum value which is stored as one of the record fields.
Repeating the process and comparing the new value with the previously stored
one will show whether the data has been really changed (i.e. not an edit that
leaves the original value unchanged)

--
Tony Bryer, Greentram Software Pty Ltd, Melbourne, Australia
'Software to build on'  http://www.greentram.com



Tue, Nov 3 2009 2:26 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Sean


If you use persistent fields what about using the fields OnChange event to set a flag? You can use one event for all the fields. Set the flag in the afterinsert event for the table. You could also use the OnKeyPress event for the TEdits or whatever you're using.

Unfortunately anything like that will still not take account of someone typing a character and changing it back to what was there.

The best way I can see is in the beforepost event have a second instance of the table (or a query) find the previous record and loop round the fields comparing them.

Roy Lambert [Team Elevate]
Tue, Nov 3 2009 7:57 AMPermanent Link

"Sean McDermott"
Hi Roy thanks, I have pretty much implemented what you have suggested but I
am also intrigued by Tony's idea. I am sure this happens quite a bit and I
know I will need it again in the future so I will invest some time in a
couple of concepts to see what works best in this situation. Thanks All,
Sean

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:59167A7A-4740-49F3-B9C2-14F5347073B0@news.elevatesoft.com...
> Sean
>
>
> If you use persistent fields what about using the fields OnChange event to
> set a flag? You can use one event for all the fields. Set the flag in the
> afterinsert event for the table. You could also use the OnKeyPress event
> for the TEdits or whatever you're using.
>
> Unfortunately anything like that will still not take account of someone
> typing a character and changing it back to what was there.
>
> The best way I can see is in the beforepost event have a second instance
> of the table (or a query) find the previous record and loop round the
> fields comparing them.
>
> Roy Lambert [Team Elevate]
>

Tue, Nov 3 2009 8:46 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Sean


That reminded me of something - have a look at RecordHash in the OLH. Naturally if you move from DBISAM it no longer exists. You could sell the idea of an extra field - calculated the first time a record is posted as a way of making sure the data hadn't been altered since I guess its series and goin back to adjust the series to fit the outcome might be frowned on.

Roy Lambert [Team Elevate]
Image