comment

Yes, just set the indexing to None + Automatically create indexes as needed.

Well, I don't think there are too many options here. At least I cannot think of any except: the field does contain a word starting with "Y"'; the index is corrupt; the file is corrupt.

Is it possible that the field actually contains something like: N Y ?

See if the attached demo helps. CondVLx3.fmp12

I don't think so. You show a relationship matching on codigopostal. You need a relationship matching on codigopostal AND ext_codigopostal. And if you want to have two conditional value lists, you will need two relationships, using two occurrences of codigo_postal table.

If you want to have a value list filtered by both Code and Prefix, then you need to also have a relationship that matches on both Code and Prefix.

I suggest you spend some time on this, because it will come handy in any calculation involving periodical phenomena such as dates and times.

If you only want to group the records by shift, you could calculate some value that will be common to all records within the same shift - a sort of an "absolute shift number", if you like: Div ( CompletedJobTimestamp - Time ( 6 ; 30 ; 0 ) ; Time ( 8 ; 0 ; 0 ) ) If you also need a label, you can calculate it from the above using: Choose ( Mod ( cShiftNum ; 3 ) ; "Early" ; "Evening" ; "Late" ) Similarly, the start date of the shift can be calculated as: Div ( cShiftNum ; 3 ) + 1 Note that this calculation assumes that a shift starts exactly at a round half-hour - i.e. a record with timestamp ending in 06:30:00 is allocated to the Early shift, while 06:29:59.999 is counted in the Late shift.

I don't think it can be done from within FMP. At least not without a plugin. If this is on macOS, you could perhaps use AppleScript to automate this. But you would need to have the export script included in each of those data files. Perhaps you should look for a better way to pass this data from A to B (the exact chain is not clear from your question). -- Please update your profile to reflect your version and OS so that we know what you can use.

I am afraid it is not simple at all. As you can see from the answer above, it needs to be scripted - and it needs to be scripted very carefully to prevent duplicates, esp. in a situation where two users create an invoice roughly at the same time. A better solution, IMHO, would be to change your numbering scheme. Note that if (as would seem from your question) you are absolutely sure that you will NEVER create more than 99 invoices in a single day, you could use a simple solution: a calculation that appends the last two digits of an auto-entered serial number to the date. But then those digits would not start from "00" (or "01") on each day. For example, the sequence might look something like: ... 21060295 21060296 21060297 21060398 21060399 21060300 21060301 21060402 21060403 ... But even here you could get a duplicate if you backdate an invoice. --- P.S. Please fill out your profile to reflect your version, OS and skill level. Upon rereading your question, I am not sure you understand the difference between a script and a calculation.

I am not sure I understand this requirement. Do you mean you want to summarize the sum of both weights by containerNumber - so that the result in your example would be: 111,27800 222,17800 333,26000 444,37000 555,16000 or something else?

I am afraid I don't see your point. In my script, the numbering does NOT "default to 1 if the teacherID and courseID aren't the same". It resets to 1 when the CourseID changes. IOW, if your found set (after sorting) is: then after running the script you will get: How is this result different from the one you expect?

Assuming you have a table of Sections, with fields for CourseID, TeacherID and SectionNumber, you can populate the SectionNumber field using a script that starts by finding the section records you want to (re)number, then does: # SORT BY CourseID, TeacherID Sort Records [ Restore; No dialog ] Go to Record/Request/Page [ First ] Loop Set Variable [ $secNum; Value:Case ( Sections::CourseID = $courseID and Sections::TeacherID = $teacherID ; $secNum ; Sections::CourseID = $courseID ; $secNum + 1 ; 1 ) ] Set Variable [ $courseID; Value:Sections::CourseID ] Set Variable [ $teacherID; Value:Sections::TeacherID ] Set Field [ Sections::SectionNumber; $secNum ] Go to Record/Request/Page [ Next; Exit after last ] End Loop Commit Records/Requests [ No dialog ] -- P.S. What's up with the bold font?

It's not that complex once it's clear what exactly you want to accomplish by it. The reason for this is that there is no correct solution to the problem. As you have noted, months do not have a constant number of days, so any calculation expressing a duration in years, months and days may be considered "correct" for some purpose, but invariably incorrect for other purposes. Replacing months with weeks does not change much, because a leap year has a different number of weeks than a regular year, and no year has an integer number of weeks. So no mater what method you choose, someone will be able to show how illogical its results are in some circumstances. For example, compare these two calculations: https://fmforums.com/topic/92520-age-from-date-of-birth-calculation-doesnt-work/?do=findComment&comment=424950&_rid=72594 https://fmforums.com/topic/89899-age-calculation/?do=findComment&comment=412505&_rid=72594 I wouldn't.

This is a bad situation no matter how you look at it. Suppose the auto-entered number is 150, and user overrides it with 200. So 50 records later, they (or another user) will get a validation error without understanding why - and without even entering the ID field. The purpose of auto-entering a serial number is to provide a unique and permanent value by which the record can be identified. If users are allowed to override the value, then this purpose is thwarted. I would suggest you re-evaluate the problem, instead of trying to patch it. If they have another way to identify the record (e.g. a barcode), have them enter it into a separate field.