Is there a calc (I know I can do this with a script) that will
dynamically number the current found count?

Example: In a 500 record database I have 20 "apple" records spread
throughout it. When I do a find for "apple" I would like the found
records to be labeled sequentially 1-20.

If I use Status(CurrentRecordNumber) I get 1, 18, 300, etc. Even after
sorting. Is there a secret? I want to avoid scripts since in my
application the found counts would number in the thousands, and a
script would take too long. Thanks for any help.

From the various trials I made over the years, the speed ratio script
over calculation is 10 to 1. Ie scripts are ten times faster than
calculations for doing the same thing. So I don't think your argument is
a good one.
Now for 'numbering' a set of records, you always may add "@@" (without
the quotes) to the record line shown in a list view. It does not insert
in the record anything but it shows a sequential number.
In a script you may use the 'Replace' step that is very quick for
numbering. But be careful in using it when in a network solution as you
may miss the records in use by another user.
Remi-Noel


"zend999" <zend999 (AT) yahoo (DOT) com> a écrit dans le message de news:
1118866280.471615.296230 (AT) g43g20...oglegroups.com...

I do what you're trying to do fairly frequently. I get an appropriate
rendering of "Record X of Y Records." Unless I totally miss my guess as to
what's happening,the solution is simple.

I'll assume you have two calc fields:

ThisRecord = Status(CurrentRecordNumber) and

FoundRecords = Status(CurrentFoundCount).

If you go into the storage options of each of those field definitions and
check the box "Do not store calculation results -- calculate only as
needed" your problem will be, as Clousseau would say, "Sol-ved."

Matt

On 6/15/2005, zend999 wrote:

Hey, that was simple! Thank you. As far as accuracy on a network goes,
it's fine. It'll be used in creating indexes, and the user just needs a
general knowledge of how many items are in the index and where they
fall.

And it's interesting that you say scripts tend to be faster than
calculations. Would you say that's the case even in my application
involving thousands of records? For a calculation to complete it seems
to add only a millisecond to the time it takes for the record(s) to pop
up. Of course if it's a really complicated calculation with related
records it can take hours (which I stupidly did once with live data and
just had to wait for the dang thing to finish). But even a simple
script would take a minute or so to sort through all those records.

I have a client to whom I made a solution with 20 files, FMS55, 8
workstations. Some of the files increase at a rate of 400 new records a
day, so I got each year a 140 000 records file ! Which is to be
consulted and updated real time. But rather complex calculations were
needed and it slowed down a bit the process. I changed them to scripts
and delay is no longer noticeable. For large files, one has to be
cautious and avoid long processes like sorting the whole file out - just
sort the records you want to display -, replacing fields contents for
more than 5000 records on a row, etc. But having that in mind you can
really build a solution that works. In this case, the application is a
pretty large store in Paris renting tapes and DVDs, and there may be
queues at the counters of 20 customers waiting my stuff to take their
problem into account. It can be to find a film, or to discuss of their
account receivable, or rent 25 films on a row - they have a complex
price list - or even maybe : "oh! you want you rent this film again ?
you already rented it 6 months ago".
For another client it is even more spectacular : I started to use
complex related calculations, but then the record took several seconds
to show up. So I rewrote the thing into a script - when printed, that
script holds 6 pages ! - and here again, time to refresh is not
noticeable (FMS55, 10 PCs).
Remi-Noel

"zend999" <zend999 (AT) yahoo (DOT) com> a écrit dans le message de news:
1119068003.237158.219410 (AT) g49g20...oglegroups.com...