Hi, Just some info for Ralph regarding the problem I was having, that I thought re-indexing fixed.
I subsequently found re-indexing hadn't fixed it and it appeared to be somewhat random in occurance but occurred sometimes when a record was edited My original auto incrementing field was sent up as non-updatable, and the when I applied the two link method I left that field with the ::N designation Sometime in the last few months I had removed the ::N designation to be able to access the field and did not reactivate it. That field was getting updated to the last number when the panel fields were updated with the F6 key by holding the F6 down and moving thru the whole panel. Didn't occur when that field was not F6'd on so took a little while to sort what the problem was. Making the field non-updatable again has stopped it happening. Apologies for the mis-leading info that re-indexing had fixed it - but all is fixed now Regards Colin ----- Original Message ----- From: "Colin Roberts" <[EMAIL PROTECTED]> To: "Dataperfect Users Discussion Group" <[email protected]> Sent: Tuesday, 22 July 2008 13:40 Subject: Re: [Dataperf] Re: Recursive link and index > Hi Ralph, > > The database (as are the 6 other database I run) was set up using the > "Absolute Incrementation Using Two Recursive Links" method, as its run on a > network and as far as I can see, still conforms to your instructions > summarised in box on page 140 of your book > > P1F2 (actually my P3F1) is edit order field 76 and P1F2 (reverse field - > actually my P3F83) is edit order field 83 > P1F3 & P1F4 (Actually P3F84 & P3F85) are linked as per instructions and both > Indexed with my Index 9 which only contains the reverse field my P3F83 > > P3F1 formula set to update when created record is saved and P3F83 is set to > update on any change > > I mentioned new records are added daily but should also have mentioned that > child panel records are often edited on a daily basis also, and this is the > 1st time the problem has occurred. As I say the re-indexing which I probably > hadn't done for a month or so appears to have instantly fixed the problem > and it hasn't as yet re-occurred again. > > Any other thoughts - not a major if the index recovery fixes it should it > ever re-occur again. > > BTW - referring to your late breaking news on page 140 - did Lew actually > change the structure so the two link method was no longer neccessary on a > network - just curious > > Regards > > Colin > > > ----- Original Message ----- > From: "Colin Roberts" <[EMAIL PROTECTED]> > To: "Dataperfect Users Discussion Group" <[email protected]> > Sent: Monday, 21 July 2008 21:36 > Subject: Re: [Dataperf] Re: Recursive link and index > > > > Hi Ralph, > > > > Changed from auto-incremental fields to your recursive link methods many > > years ago (more than I care to remember :-) and when set up your rules > were > > followed. There is a chance that maybe the edit order may have been > changed, > > and I'll need to get out your book and check tomorrow. Haven't got access > to > > your book at present, but from memory I think I remember the edit order > > between the two recursive link fields was important and I'm pretty sure > the > > edit order relationship between those two fields hasn't been altered even > if > > the edit order of the panel may have been modified as new fields have > been > > added over time. > > Database is extensively used and new records added daily - this is the 1st > > time I've ever had such a problem and re-indexing appears to have fixed it > > (at this stage?). > > > > I'll recheck your rules still apply tomorrow, and get back with my > findings > > > > Thanks for responding so quickly > > > > Regards > > > > Colin > > > > > > ----- Original Message ----- > > From: "Ralph Alvy" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Monday, 21 July 2008 17:51 > > Subject: [Dataperf] Re: Recursive link and index > > > > > > > Colin Roberts wrote: > > > > Long estblished Database - 35000 parent records and 85000 child > records. > > > > > > > > Edited a child record (one of 20 child records of that particular > parent > > > > record) via the parent record and found that when saved, the child > > record > > > > picked up a new recursive number on saving. Was able to remove non > > updatable > > > > field designation and put indexed recursive number back to what it was > > and > > > > all looked OK. Editing of some other child records sometimes did the > > same > > > > thing (created a new number) and sometimes it saved OK retaining the > > > > originally allocated number. There was never any error message or bomb > > out. > > > > Re-indexing database seems to have got rid of the issue, which I've > not > > ever > > > > experience B4 - and not sure exactly why or how a saved record can > > generate > > > > a new number when edited - no other user was accessing database at > same > > > > time > > > > > > Did you make sure the Edit Order followed the rules outlined in my book? > > > > > > Did you make sure the Update Conditions are following those rules too? > > > > > > Ralph > > > > > > _______________________________________________ > > > Dataperf mailing list > > > [email protected] > > > http://lists.dataperfect.nl/mailman/listinfo/dataperf > > > > _______________________________________________ > > Dataperf mailing list > > [email protected] > > http://lists.dataperfect.nl/mailman/listinfo/dataperf > > _______________________________________________ > Dataperf mailing list > [email protected] > http://lists.dataperfect.nl/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
