most recent records question

[Fairlight]

In the relative spacial/temporal region of
Mon, Jul 26, 2004 at 06:13:28PM -0500, Richard D. Williams achieved the spontaneous
generation of the following:
> Bob,
> 
> It was always my understanding it was a no-no to building indexes on 
> system maintained fields.
> Is this no longer correct?

I think this may have more to do with @rn than anything else, but that's a
rough memory.  I thought I remembered seeing it expanded to "all system
maintained fields" as a general rule, which is why I asked in the first
place.

Sorry for my assumption that @ct exists.  Oops.  Didn't mean to hit the
sore spot, John.  You should probably forward that to fpsupport, btw, or it
won't be "official" and recognised as such.  Or at least submit it on the
wish list.

> Mark,
> 
> Could you build another file with real fields to hold these system 
> maintained values and use it to get you
> where you want to go?

Well, I can build the tracking with processing-maintained fields, no
problem.  The problem lies in resolving these to the tables and fields to
which they refer.

Assume I have a time span of 5 minutes between updates of my proposed
pseudo-RSS feed.  Assume I have all the pieces in place, and all you ever
need to do to tell a transaction to update is set something like the
following in your own code:

::declare global FLRSS_Type, FLRSS_Fields, FLRSS_Key_Data, FLRSS_Key:
::FLRSS_Key_Data="some_unique_id_for_original_record";FLRSS_Key="field_num":
::FLRSS_Type = 'add';FLRSS_Fields="1,3,7.9.10,12,15,18,22";
::call "flrss/do_transaction":

So you create a record in the transaction table which the feed is based
upon which exports those fields in the feed when it regenerates the feed
file, and say it's type "add" so it uses the proper lookup for a free
record.

But...let's say that a minute after that, someone realises they screwed up
their data entry and goes in and does an update.  If I handle transactions
in descending order, we're doing an update on something that hasn't even
been created yet.  That would never be found.  Same thing if we had a
record that someone immediately deleted.  For the reasons of deletion, I'll
never be able to depend on @rn either, so a unique identifier is manadatory.

The solution would -appaear- to be to grab the most recent entries for a
time frame from the main transaction database, then copy their entries to
an identical table whose index is build in -ascending- order so that all
entries are exported in the order in which they occurred--while still only
grabbing the ones within that time frame.

I think.  Maybe. *chuckle* I'm still kicking this around.  The spec I
tossed out last week was the -easy- part for me.  The fP-centric part of
it is what I said would be hardest for me personally, and it is.  I'm not
used to thinking like this.  I wish there was a way you could just grab
a set of records, store them in their entirety as data structures in an
unlimited-length dynamic array, and then reverse the order of the array,
without all the intensive disk I/O entailed in my proposal here.  Trivial
elsewhere, and I'm not knocking fP, but I'm coming up with what feel like
kludgy solutions within its framework.  Probably because I'm not used to
it, and you folks do it 40-80hrs/week.  There's bound to be something more
elegant.  I'm still in the initial thinking stages of this.

Someone pass me a Tylenol.  <Onslow>I got headache.</Onslow>

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html