• Content count

  • Joined

  • Last visited

  • Days Won


comment last won the day on March 23

comment had the most liked content!

Community Reputation

1,312 Excellent

About comment

  • Rank

Profile Information

  • Gender
    Not Telling
  1. If they are based on the same TO, then moving from one to another does not change the current record. So this entire part: can be reduced to just: which is rather trivial to translate to a script: If [ Get ( LayoutName ) ="MAIN" ] Go to Layout [ “BACKUP” ] Else If [ Get ( LayoutName ) ="BACKUP" ] Go to Layout [ “MAIN” ] End If The only problem with this approach is that if you change the name of a layout, you also have to change the string in the corresponding If/ElseIf step. There are ways around that, but they require more work - and with a just little more work you can have a dedicated button on each layout, as I suggested earlier - and as I will suggest again now: I am not sure what this has to do with anything. The original post discusses two layouts only. You can have as many other layouts as you like, and the two layouts in question don't need to be next to each other. Just place a button on the MAIN layout to go to the BACKUP layout (by name), and a similar button on the BACKUP layout to go to the MAIN layout and be done.
  2. Think how you would do this manually - then tell your script to do it for you. I don't know what your exact rules are, but I can give you an example: pick a random number for $a; populate all records with FieldA = $a and FieldB = serial incrementing number; pick a random subset of records and set FieldC to the result, then clear FieldB; sort by random.
  3. Are the two layouts also based on the same table occurrence? If so, all you need to do is go to the other layout. Again, no script is required: just set each button to go to the "other" layout.
  4. Why don't you define a relationship between the two tables (assuming the two layouts are showing records from two different tables), then use Go to Related Record[] as the button action (no common script necessary)?
  5. I am not sure I followed your description fully. From what I think I understood, I believe you should have a permanent bank of records, in the amount that corresponds to the maximal number of questions you want to present at one time. Then have a script populate those records, optionally omit some to reduce the number of questions, and shuffle them. You can have the script randomly populate either b or c. The problem then becomes how to present the two types so that the subject can only enter an answer into the blank field.
  6. This is very different from what I suggested:
  7. Basically, you have two options: 1. Import the file twice, once into the Payments table and once into Orders. In each table, define a Type field and set it to validate by calculation: Self = "Payment" and: Self = "Order" respectively, validate always. When importing, map the keyword to the Type field. 2. Import into a temp table first, then do a find for each type and import the found set into the corresponding target table. Both options can be scripted so that the user only needs to select the file.
  8. A zero is zero, no matter how it was entered. And GetAsText ( 0 ) ≠ GetAsNumber ( 0 ) returns false. IMHO, your real problem is having 90 fields - and I suspect you will run into it again.
  9. No, I don't think so. This is the second time you report a behavior that I cannot reproduce. Are you sure you're using Filemaker?
  10. I don't know of a way to find them in the existing number field. You would have to construct a calculation field along the lines of = GetAsText ( YourFirstField ) ≠ GetAsNumber ( YourFirstField ) and search for 1 in this field. Of course, with 90 fields, this is not practical.
  11. You have 90 number fields in the same table?! Surely, that's a symptom of wrong structure. You should probably have 90 related records in a related table. Unless you fix this, you will have to repeat any cleanup measure 90 times. That is not my experience. Searching for ? in a number filed will find only records that contain a value with no digits - i.e. a value that cannot be converted to a number using the GetAsNumber() function. It will not find a value of "12..345" or "1.2.3". You didn't say how you tried to clean them up. 40k records is quite a small number, even times 90, so I don't see what could take upwards of 3 hours. The correct way to clean this up is more or less what Vaughan suggested in the second part of his post: 1. Make a backup; 2. Show all records; 3. Click in the first field and replace the field's contents with a calculated result = GetAsNumber ( YourFirstField ); 4. Repeat 2 & 3 90 times. This could be scripted, but it would be much better to have a single field a related table first, so you only have to do it once. Not to mention other benefits of normalization. @Vaughan You shouldn't take OP's word for granted. GetAsNumber ( Self ) will fix double dots just fine. Except you cannot use Self when replacing field contents. P.S. Nice to see you back.
  12. I am afraid I cannot look at your file. In case it wasn't clear, you need to run a script that will create a record in the Emissions table for each combination of EngineYearlyConsumptions and Substance (i.e. every row in your report). There is no other way to populate the table (unless you want to do it manually, or you have an outside source you can import)).
  13. No, There are no named relationships in Filemaker. Date_match is the TO to which the layout named "staff_schedule_match" belongs. When you execute this step, you are placed in the context of the Date_match TO. I don't see your graph, so I am not sure what exactly that means. And I am afraid I don't follow your initial explanation well enough to understand what you want to do. But I can tell for sure that you are trying to set fields in the staff_schedule_match TO, while you are in the context of the Date_match TO - and since these two are unrelated, you are getting an error. And I can also say that relating them artificially is not the solution, because while you are in Date_match, the only record in staff_schedule_match you'll be ever able to modify is the first one.
  14. That's not how the Go to Layout [] step looks like. If you take a look at your actual script, you'll see it's structured like this: Go to Layout [ “Layout Name” (Table Occurrence Name) ] In your example, that should translate to: Go to Layout [ “staff_schedule_match” (staff_schedule_match) ] Judging by your error, you are seeing something like this instead: Go to Layout [ “staff_schedule_match” (Some Other Table Occurrence) ] because the layout named "staff_schedule_match" is defined to show records from Some Other Table Occurrence. BTW, this has nothing to do with variables. You will get the same error if you try to set any of the fields to a constant value.