IMHO, it really was just a small glitch in the custom function, and I credit Torsten’s eyes for catching it.
With the loop, it played out in a big way, but that indirectly brings me to something clear to me on this thread:
This forum, and all the participants with their distinct input, is a really valuable asset as we do our work.
I happen to have slacked off on my FMP work, and so I would not have easily seen that space char – but, it just so happens that the work I have been doing recently requires optimizing repetitive js code that is executed countless times. And so, it was natural to have some curiosity about how much was adding up when a loop is involved – I’ve had to do the same with my code every week for the last four months, and each time I’m always a little stunned at how some small changes can make a big difference in total overhead. I am getting off-point, however – what I meant to underscore is how happy I am to see this community, because I think the ability to easily reach out to and interact with multiple sets of eyes and experience is so valuable, especially when we are coming at things from different angles. I’ll try not to belabor this point further, as I suspect that I’m preaching to the choir – but, seeing things take off here at fmsoup is very satisfying.
Another takeaway:
Another takeaway is, of course, as Torsten has pointed out: the value of type casting and/or data sanitizing.
And one last thought:
I seem to recall some long and lively exchanges on the old forum about how FMP stores numeric data. Devs were weighing in on whether or not the data is stored as a string, as a number, or as both. I read that one with interest, but don’t feel like I saved a solid understanding from it. I do think it may be relevant to this thread, though.
At APAC meetings the FMI engineers told us that FMP stores the original value that is pasted, in other words it is stored as a string. If you paste “INV008” into a number field it will display “8”. When you enter the field it will display “INV008”.
From memory, text fields will generate two indices, if that setting is allowed, whereas number fields will not generate the second index. ( The word index ) Also, performing number operations on number fields was faster ( by a small percentage ) than performing the same operations on text fields. Some actions, like summary fields, will not allow you to select text fields as targets, but that is an obstacle that you can step around by defining your own calculations.
It’s nice to see some numbers. I was wondering if the script had been triggering the building of indices as they could increase file size dramatically. The aggregation of characters makes sense of the file bloat.
A value may be stored in a way that suits the internal handling of the format. Externally (developer/user-facing) it should be consistent with the format. Anything else has the potential of seeding confusion.
The message from them was that deep down inside the database there was not a different storage method for numbers. In SQL databases you can define field types with fixed lengths. The database engine can optimise space requirements on that basis and it will only accept data inputs that match the specifications. In FMP, the draco engine will try to optimise, based on expectations, but deep down in the core, the same storage structures are used for all the field types. The UI will try to prevent you from entering nonsense, especially in date and time fields. You can get around this by using scripts.
