comment

Members
  • Content count

    27,514
  • Joined

  • Last visited

  • Days Won

    510

Everything posted by comment

  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.
  15. Again, you will need a table where the yearly engine consumption data is stored using an individual record for each engine/year combination. I don't know how you're getting your data, but ideally you would have: Engines -< EngineYearlyConsumptions -< Emissions >- EmissionFactors Note that a record in Emissions table must lookup the YearOfManufacture and HorsePower values from its ancestor in Engines, in order to link to the correct record in EmissionFactors.
  16. I no longer see an option to select the font, or indent a paragraph (and, IIRC, a few more formatting options).
  17. You have to start by splitting this into individual records in an EmissionFactors table that has fields for: • Substance • YearOfManufacture • MinimumHorsePower • EmissionFactor • Units Then for your report generate a record in a third Emissions table for each Engine/Substance combination, and let it calculate the total emission. So your structure would be: Engines -< Emissions >- EmissionFactors and the relationship between Emissions and EmissionFactors would be defined as: Emissions::Substance = EmissionFactors::Substance AND Emissions::YearOfManufacture = EmissionFactors::YearOfManufacture AND Emissions::HorsePower ≤ EmissionFactors::MinimumHorsePower with the records on the EmissionFactors side sorted by MinimumHorsePower, descending. I don't see a given year in the example. If you have year-by-year data, this may affect the structure.
  18. Make sure to read this: http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf
  19. Make sure the summary field is not defined as running total. Otherwise it will always show the value of the first related record, no matter what you do. Please note that I have added an alternative method to handle this, also using your existing relationship. This is crucial. If every invoice can have its own "delay", stored in the invoice itself, then the task of creating a relationship that shows only invoices past their due becomes even more complicated. I won't go into it now - if you like, do a search here for "Ugo's method".
  20. No, the words "unstored" or "current date" do not appear above my previous post. Anyway, I already gave you two ways to do this with your current relationship. If you want to define a new relationship, then explain exactly how the Late flag is calculated - including how any calculation fields it depends on (such as DueDate) are calculated.
  21. How exactly is the Late field defined? If it's an unstored calculation (as it probably must be), then it cannot be used it as a matchfield in the proposed relationship.
  22. Then you will have to either change the relationship so that it includes the filter, or place the text object inside a one-row portal filtered the same way. Or define a calculation field that returns the invoice's sum when the invoice is late and sum/summarize it instead.
  23. I think you could replace the portal by a text object and merge the summary field (defined in the portal table) into it. This assumes the portal has no filtering applied to it. I am mostly guessing here, because you did not explain what exactly the portal is showing and how the underlying relationship is defined.