![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
![]() |
Mon, Nov 2 2009 2:13 PM | Permanent 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 PM | Permanent 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 PM | Permanent 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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] |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |