Status (CurrentRecordNumber)

[longjump]

When I use "Status (CurrentRecordNumber)" in a calculation it seems always to return the same number for a given record, regardless of the size of the found set and regardless of the sort order. It's as if it's returning the Record ID, not the Record Number.

From what little I can find in QuickHelp or the user's manual or the filemaker.com knowledge base (and that's *very* little), Status (CurrentRecordNumber) is supposed to indicate where the record is in the found set. But I can only get it to indicate where the record would be if you did a Find All and did not sort the found records.

Edited March 26, 2006 by Guest

[ThatOneGuy]

Hi Longjump:

Try setting your calculation to "Unstored."

[longjump]

Thanks much ThatOneGuy, I thought it'd be somp'm simple like that

I realize now that this issue exists w/ other status functions too. The fact that not storing calculations causes them to be calculated more often seems counterintuitive (at least semantically if not logically) to fm's assertion that unstored calculations "calculate only when needed". Maybe this is one reason why I've always found the storage subject a bit mystifying. Luckily[?] I've never had this prob before even though I use many status functions in many db's and have never bothered to set storage options manually.

I'm trying, unsuccessfully so far, to find an online primer or discussion on the basics of storage. Help and user's manual are too sketchy whereas the many posts I've found so far on the subject are too specific. Got any suggestions?

Thanks again

[ThatOneGuy]

Hey, glad it worked for you!

I'm trying, unsuccessfully so far, to find an online primer or discussion on the basics of storage. Help and user's manual are too sketchy whereas the many posts I've found so far on the subject are too specific. Got any suggestions?

That's a better question than one may think at first blush, and you'll find it's a consideration more frequently once you move from FM5 to FM8. This won't be the definitive "last word" on the subject, but let's see if we can flesh out some aspects of Field Storage. (Okay, where to start?)

Indexed fields will increase the file's size.

Unstored fields take longer to calculate.

You'll need Indexing ON if the field will be used ...

• in the "child-side" of a relationship
  
• to perform a Find; otherwise, searching can (will) slow down
  

FM5's default of Indexing OFF with "Automatically turn indexing on if needed" activated will be fine in most instances.

In FM5, Storage is UNSTORED when (1) Indexing is turned OFF and (2) "Automatically turn indexing on if needed" is DEactivated ... this is the case for both calculation and non-calculation fields, and it is essentially the same under FM8 for NON-calculation fields. For calculation fields in FM8 however, those two factors are combined into a single "Do not store calculation results -- recalculate when needed."

"By default, calculations that include a related field, summary field, global field, or a reference to another unstored calculation are unstored; all other calculations are stored." ... from FM8's built-in Help (which I think has a better explanation about Storage than that in FM5, but still applies under FM5, AFAIK).

Which brings up Global storage. Under FM5, "Global" is a FIELD type. This changed (I think most would agree, for the better) beginning with FM7 where "Global" is now a type of STORAGE.

As for FM5's "Status" functions, I think you'll get your desired result most often by making those fields UNSTORED. Some of our forum's gurus can probably illuminate us both on this. In FM8, these functions have been re-categorized (and greatly expanded) as "Get" functions ... which kinda helps eliminate that semantic inconsistency you detect.

I hope this helps, and I hope others will chip in some thoughts. Of course, if I've misstated something, our resident experts will set the record straight.

[longjump]

Yep, that does help. Good info. Thank you.