Automatic Index Flashback (was: Re: Demand Indexes and deleting records.)

Richard Kreiss rkreiss at verizon.net
Mon Dec 14 22:38:48 PST 2020


I have a client who uses the demand indexes, all of them, with selection sets to limit what records are available to his call center. 

As I stated previously, the is an issue with browse lookups as the records that are displayed have their record numbers in an array to allow for faster redisplay. This is only an issue with the faster network connection and drives. When a displayed record is deleted, it is possible for a new record , just added, to be displayed. This happened to one of my clients and it took Jen Brody, looking at the source code to come up with a solution. I needed to add a drop on the order #. John Esak needed to do the same thing as he was on that call. 

When used properly demand my and indexes are useful. Nancy should rebuild the demand index after deleting records. One would need to use the new functionality of using a selection set with an auto index which could use the creation date field to insure new records are not picked up by the index. One could set @cd ne to td( today’s date) 

Richard Kreiss
GCC CONSULTING 
Sent from my iPhone

> On Dec 14, 2020, at 11:50 PM, Jay R. Ashworth via Filepro-list <filepro-list at lists.celestial.com> wrote:
> 
> ----- Original Message -----
>> From: "Nancy Palmquist via Filepro-list" <filepro-list at lists.celestial.com>
> 
>> filePro People,
>> 
>> I just noticed a very strange thing but it makes sense in a way.
>> 
>> Once a week I build a demand index with the oldest stuff in a very large
>> database.  I then run through that index and delete items until I run
>> out of time.
>> 
>> So I have an index with some items deleted and some not.
>> 
>> What I just noticed is that when new records are added into the slots
>> where records were deleted, they seem to be included in the index. It
>> makes sense in that the index has record pointers.  The data is not in
>> sorted order but it is picking up the data on the record as if it should
>> be in the index.
>> 
>> I offer this as a caution that if you are depending on a demand index to
>> remain the same, you may be surprised if you are deleting records to
>> find new records in their place in the index.
> 
> Well, automatic indexes do this too -- if you change the index field while
> you are walking an automatic index, *it looks at the changed data* to decide
> where to go next at the end of processing.  That cost me 3 or 4 days, while
> coding some stuff back in 1995 or so -- that code, if it still exists, has
> a comment about *exactly where in the sources for 4.2* that design flaw occurs
> (the client was a 3b2 beta site, so I actually got to look it up for my bitchy
> comment).
> 
> I forget now how I fixed it...
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list



More information about the Filepro-list mailing list