Buggy portal behavior?

[-Queue-]

I dig this idea. The problem is what Ugo's concept 'opened my eyes' to before. If a record is deleted, the technique falls apart. Is the case similar with this one? That's why I was working on getting away from the binary idea, unless Status(CurrentRecordNumber) is used and updated after any change of the found set.

[DanBrill]

Hats off to you, E Springer. This is a really interesting technique, and I've had fun catching up on this thread. One thing that I don't think has been mentioned is that, portals aside, this could be very useful for recalling a found set of records. Since each found set will produce a unique sum, that sum could be saved and recalled later.

For example, suppose you perform operation X on record set Y at time Z. Later, you want to know which records were members of Y when you performed X on. You could retrieve your sum and reproduce the record set that existed at Z. For example, "which records in my contact database received the mailing that went out on Jan 5th" could be stored as a single number.

For a minute I was thinking that you had found a 'holy grail' of FileMaker -- allowing users to save their complex finds. But this would only be true in a finite set of records. If records are added at time Z+1 that matched the find criteria at Z, they wouldn't be recalled.

So have you thought about how much further the limit could be increased? Thinking out loud here, but would it help with FM's storage limits if the numbers were converted into hex or a higher base?

In any case, very nice work.

Dan

[ESpringer]

Thanks, Dan! I figured this thread wouldn't get much more attention, happy I was wrong.

I don't imagine this trick will have too much application for recalling, say, which records get a certain operation performed on them, though... for one thing, it's not really one binary number, but a set of binary numbers, each one tracking a batch of 40 records (It could be up to 49, I believe, though I may find some trick to make it an even 50). For another thing, this method wouldn't save any data storage space compared to making a new dedicated binary tag field in all records; the amount of storage is basically 1 bit per record with data. There's also the problem that as records get deleted and added, it's necessary to "compact" the record numbers again, to avoid letting the binary numbers get too big. But that means reassigning the numbers. So if you had a certain binary number, it's usefulness wouldn't survive the renumbering...

I'm *very* curious about how far the limit can be pushed. Fenton's numbers [sorry for misattributing earlier!]

32,767 characters limit to calc field

should help us figure that out, but I haven't bothered to track down their implications yet...

[ESpringer]

Queue,

My found-set portal *shouldn't* have any problems coping with deleted records. Indeed, it shouldn't have problems with *any* operation conducted on the fly -- no scripting or handholding needed... except for preventing duplication of serial number, which is accomplished by the field being auto-enter and validated as unique. (It doesn't prohibit modification because occasional compacting script needs to be able to renumber.)

Even exceeding the record count shouldn't mess up the portal's ability to report on records whose numbers are below the threshhold (that wasn't true for my earlier solution; it would just break in an ugly way).

Of course, the deleted record's number will show up in the LH self-join key list, and so do numbers for not-yet-created records, but that's no problem -- the non-existent record can't show up in the portal, 'cos there ain't no record there.