I've built a layout that I love, but it takes too long to load -- it loads in list mode.. and looks kind of like a spreadsheet but with lots of cool bells and whistles...

I'm thinking I can dramatically reduce load time if I only load the first 30 records at a time and then have a "<<prev 30" "next 30 >>" option to scroll to the next/prev page of records.

Could someone tell me the basics for how this is achieved ?

The easiest way, but perhaps not really getting around the problem, would probably be to loop through the record, assign a number to a field (ThirtyRecordSetNumber). Whether or not this helps really depends on how many records are in the found set and whether the speed problem is due to the computer calculating summary fields, and it may not give you what you want in that case, as the data in the found set may not be showing the proper values in those summary fields. It really depends on what the speed issue is.

Assuming you wanted to do this, you might do it like this:

Set Field [ gCounter, 0 ]

Set Field [ gRecordSetNumber, 1 ]

Go to Record/Request[ First ]

Loop

  If [ gCounter = 30 ]

    Set Field [ gRecordSetNumber, gRecordSetNumber + 1 ]

    Set Field [ gCounter, 0 ]

  End If

  Set Field [ ThirtyRecordSetNumber, gRecordSetNumber ]

  Set Field [ gCounter, gCounter + 1 ]

  Go to Record/Request [ Next, Exit after last ]

End Loop

If the speed problem is due to summary fields, make sure that you run this portion of the script with a layout that doesn't have those summary fields.

Now, adjust your find criteria elsewhere in the script to account for the contents of the ThirtyRecordSetNumber, track which set you're looking at, and your next and previous can do the finds for one greater or one less than the current set.

However, this may not solve the problem. Again, it really depends on why the speed is slow. If it's simply because there are so many records, or because the search is taking so long because you're searching thousands of records on an unindexed field, this will do nothing to speed it up.

Chuck

neat. I'll try that soon. thanks

there aren't a ton of records.. about 1000 max.. but there are about 200 fields in the main table .. quite a few of which are calculated fields

would it help to index as many text fields as possible ?

i'm pretty new at filemaker..

i think the layout might be taking a while also because i have some graphics on it... not too man..

but it's in list format and is rendering 300 or so x 4 or 5 little graphic pictures.. (little pencil icons, trash cans.. things like that)

Set Field [ gCounter, 0 ]

Set Field [ gRecordSetNumber, 1 ]

Go to Record/Request[ First ]

Loop

  If [ gCounter = 30 ]

    Set Field [ gRecordSetNumber, gRecordSetNumber + 1 ]

    Set Field [ gCounter, 0 ]

  End If

  Set Field [ ThirtyRecordSetNumber, gRecordSetNumber ]

  Set Field [ gCounter, gCounter + 1 ]

  Go to Record/Request [ Next, Exit after last ]

End Loop

It can be done much faster:

--sd

Replace Field Contents [ Untitled::TheField; Replace with serial numbers: Entry option values; Initial value: 1; Increment value: 1 ] [ No dialog ] 

Replace Field Contents [ Untitled::TheField; Replace with calculation: 1+Div ( Untitled::TheField ; 30 ) ] [ No dialog ] 

Replace is indeed faster, but can be more dangerous. If this will be a multi-user solution, you are better off never using Replace Field Contents and going with a Set Field loop instead. You should also add a Set Field [somefield; somefield] and then test whether the last error is 301 and determine what to do if the current record is locked.

I did also think of this:

Go to Record/Request/Page [ Last ] 

Loop 

       Exit Loop If [ 1  xor Get ( FoundCount ) ] 

       Set Field [ Untitled::aField; 1+Div ( Get ( FoundCount ) ; 30 ) ] 

       Omit Record 

End Loop   

Because it could be perfectly legitimate request not to litter a database with globals ...at least do I always seek to do so, but instead rely on scriptparameters....Especaially in this case with an already pretty flat'ish structure only leaving some room for relational data as a golden principle

But it have the same record locking flaws to handle - which though can be circumvented by Jon Rosens

method from Advisor: http://advisor.com/doc/07200

We're not few of us, who have expirienced an employe leaving his desk for lunch, without exiting the record he just worked in ...some kind of scheeme has to take care of this anyway.

--sd

There are two problems that djbeta has - one is getting just 30 or so records displaying at a time and you genii have suggested many fixes for that.

The other is the slow display of the list screen. This is almost certainly due to all the pretty bells and whistles he has added. [i inherited a trivial list view of records using dotted record separater lines and field borders - all treated as graphics by FMP. Changing these to simple lines reduced display time by 90% +/- a bit.]

. This is almost certainly due to all the pretty bells and whistles he has added

Very likely indeed!!!

--sd