Status(CurrentRecordNumber) invalid in CDML?

[Alderete]

I have two calculated fields defined in my FM database:

- cn_current_found_ct = Status(CurrentFoundCount)

- cn_current_rec = Status(CurrentRecordNumber)

When I display these fields in a CDML web page, I get incorrect results:

- cn_current_found_ct: evaluated after find and sort (e.g., in relation to found set)

- cn_current_rec: evaluated before find and sort (e.g., in relation to entire DB, not found set)

I found one or two threads regarding this incomprehensible behavior, but they all date back to previous versions of FileMaker (2-3+ years old posts). It makes no sense that one calculation would be pre-find/sort and one one post-find/sort, but it's clearly what is happening. What's truly upsetting is that this defect still exists in the product 3-4 years after it was first described here!

Is there a workaround or fix for this crazy behavior?

Note: PLEASE don't suggest I use [FMP-CurrentRecordNumber] because I can't, or I would.

[Ugo DI LUCA]

Note: PLEASE don't suggest I use [FMP-CurrentRecordNumber] because I can't, or I would.

But I'd suppose you're using Status(CurrentRecordID), not Status(CurrentRecordNumber) as your calc shows...

This StatusRecordID was designed for web use, and

"provides access to a unique ID that is specific to one record in the database regardless of the current found set or sort order, in contrast to the Status(CurrentRecordNumber) which changes based on current found set or sort order."

[Alderete]

But I'd suppose you're using Status(CurrentRecordID), not Status(CurrentRecordNumber) as your calc shows

No. I understand quite well the difference between Status(CurrentRecordID) and Status(CurrentRecordNumber), and I'm definitely using Status(CurrentRecordNumber) for a reason.

And even if I had it wrong, it wouldn't make it any less wrong that FileMaker behaves as I described in my original posting. Is there any remedy for that incorrect behavior?

[Garry Claridge]

I don't really understand the problem!

The "CurrentRecordNumber" is the number of an individual record within a found set. It is not the count of a found set (unless you went to the last record and displayed the "CurrentRecordNumber").

If you did a "-Find" and it returned 10 records, how would this CDML look:

[FMP-Record]

[FMP-Field: cn_current_found_ct ] [FMP-Field: cn_current_rec ]

[/FMP-Record]

Is this the logic that you expect or have I missunderstood you?

All the best.

Garry

[Alderete]

If you did a "-Find" and it returned 10 records, how would this CDML look:

[FMP-Record]

[FMP-Field: cn_current_found_ct ] [FMP-Field: cn_current_rec ]

[/FMP-Record]

In this case, the results might look something like this:

10 1

10 207

10 17

10 3491

10 43

10 294

[...]

That is, the Status(CurrentRecordNumber) looks random. Instead, it should look like:

10 1

10 2

10 3

10 4

10 5

[...]

I.e., the calculated field containing Status(CurrentRecordNumber) should be sequential and start at 1. That's how it looks when you view the field in FileMaker after doing the search that returns the 10 records. Only when viewing the field via CDML does it show the seemingly random (but really pre-find and pre-sort) record number.

Now, if I was just displaying the record number, there are other ways to do it. But I need the accurate record number in the found set in order to calculate "skip" and paging forward/backward navigation links. Since CDML can't even add 1 + 1, I need to do the calculation in FileMaker, and read it out for use via an [FMP-Field: cn_current_rec] in the HTML. But because the Status(CurrentRecordNumber) is always off when evaluated by the Web Companion (unless there is no find or sort), it makes the calculation impossible.

Hence, my desire to find a way to get the calculation to work correctly.

Note: I know I could use JavaScript to do calculations based on [FMP-CurrentRecordNumber], but I don't want to require JavaScript. And anyway, that's a hack around what is clearly a defect in FileMaker Web Companion.

Status(CurrentFoundCount) is evaluated post-find/sort, and Status(CurrentRecordNumber) is evaluated pre-find/sort. That's inconsistent, and evaluating pre-find/sort is useless, so it's hard to argue that it's not a defect.

[Garry Claridge]

I have just posted this solution into another thread:

I did a quick test and found the solution

Check the "Do not store calculation..." in the "Dfefine Fields - Storage Options".

All the best.

Garry

[Alderete]

I did a quick test and found the solution

Check the "Do not store calculation..." in the "Dfefine Fields - Storage Options".

I suppose this is the FileMaker equivalent of asking if you have the power cord plugged in. Even though it seems obvious, you have to ask the question anyway, just to make sure. ;-)

At any rate, yes, I certainly know that any field definitions that use the Status() functions need to be Unstored. Sorry I didn't make it clear in my original posting. This was most definitely not the problem, as all my calculated fields were Unstored.

In any case, I got around the issue by pre-calculating the Status(CurrentRecordNumber), and Replace()ing it into an equivalent entry field in a script that fires in the regular application (FM, not CDML) whenever new items would be added to the found set. This lets me simply access the en_current_rec field in my CDML, and not worry about it being evaluated, because it's just a static number.

Pain in the ass, but it works.

[Garry Claridge]

The "Status(CurrentRecordNumber)" works fine, for me, after selecting the "Do not store..." checkbox. The results are updated with every query and the CDML listing gives the numbers as expected! For example:

10 1

10 2

10 3

10 4

10 5

[...]

All the best.

Garry