stefwef

Each team gets its own interface file (entirely identical) and data file (entirely identical except for data). The teams don't want their data merged into one file for security reasons so I have to do it this way. Also, merging the data was problematic with privileges on merged records, as the only way I found to permit access to only your team records was to set privileges using a global field, and that SLOWED down performance to an unacceptable degree. If I had FMP advanced I could remove the "show all" and what not and force you to navigate only to your related records, but unfortunately I don't have fmp advanced. The script that calls all files is only used for people who have multi-team privileges. That's ok - I just spelled them out. Works like a charm, even if not very elegant. Thx!

Thanks! But what I'm wondering is if you can call a script from an external file when the call to the external file uses a variable. I have a solution that calls the same script in many identical files - only the IP host and filenames vary. So I set my call to: fmnet:/$hostIP/$filename I then perform script (Startupscript in fmnet:/$hostIP/$filename) from original file, passing a parameter. However, it won't let me select the script since the call uses variables. Is there a way to do this?

The issues with UI/data separation just keep popping up as I go along! In my integrated file I had privileges set for record access (deletion in particular) that referred to the layout the user was in (layout that is now in the UI file). With separated UI/data, the privileges calling on layout names or layout tables are no longer protecting my records. For example: --> I do not want to prevent deletion entirely in that layout, and I do not want to permit it entirely either. --> I want to permit deletion when child_table::field <>"√" --> I want to allow deletion of records (including child records that are √) when the parent related record is deleted. So my "delete" privilege was set to limit calc: NOT(get(layoutname)="layouts of child table" and child_table::field= "√") I guess the calls to get(layoutname) now refer to the external data file's layouts (which are hidden). If I force the external file to go to a layout by the same name, then it works again... very convoluted and a route I'd rather not employ. If using layout names is not best practice for record privileges, does anyone know a better way to achieve this type of record access level -- bearing in mind that I don't have fmp advanced so I can't create custom menus? (I would just disable delete and create, and replace all while I'm at it). I am limited to fmp 9 as that is what our office is equipped with. However - if it comes to that (fmp advanced)-- if I can find someone who has it, could I just create the menu and then return to fmp 9 (not advanced) to pursue the work? I'd be most grateful for any pointers. Thanks!

Well, I'm writing a book here, but hopefully this will save someone else a lot of pain. I found this on the fmp website: "Also, if the file is shared and the Boolean calculation that determines record access privileges contains one or more global fields, you may be able to improve network performance by moving some global fields into a separate table. " Talk about slowing down performance! to a standstill!

I am passing a parameter to a script, which in turn calls a script in another file. The initial parameter determines which file gets opened. Is there any way to call an external script when you are using a variable filename? I think I know that the answer is no in FMP9.0v3 but perhaps I'm missing something. Would fmp 10 allow this? I'm considering the upgrade... thank you!

I am using export to Get(TemporaryPath) & "temp.fp7" (from a database that is served) then an import to create a bunch of related records upon record creation in the parent table/served file. However, I keep getting the error: ""temp.fp7" was not created by Filemaker or is severely damaged and cannot be opened" It looks like get(temporarypath) goes to : Macintosh HD/private/var/tmp/folders/501/TemporaryItems/Filemaker/ However I don't seem to have a "private" folder on my computer and "temp.fp7" does not get create. THEN, if I change to get(desktoppath), the file DOES get created on my desktop but it won't open / says it's not created by filemaker or corrupt. Am I missing something? Never mind - I set it to unicode and all of a sudden it works...

Well, as my husband likes to say, "now I'm cooking with fire". So the slow navigation issue stemmed entirely from privileges to data records, which were set to check on whether a global (team) = record's field (team). When I remove this, all of a sudden my layouts are super fast. So - I am removing them! My plan was to use different launchers to set each team / and use the same set of usernames for each. I guess that will not be possible - will have to set team specific usernames instead. The table slowness was a different issue - and I maintain entirely caused by the external data file...until I am proven wrong! ;o)

To recap: You currently have only ONE table with fields recipe, food and #? You want to get a total of # for each food (regardless of recipe)? Do you want this as a dynamic value (you can see in browse mode) or is a printed report sufficient? (See recent posting about fruit.)

Is the first row of portal showing in browse mode? Are rows 2 and beyond in the portal printing where they should (ie leaves a blank space for first row) or are they collapsing up?

Do you want #boxes per fruit across orders or just within one order? I think if you just want a report you can create a summary field in items=total of #boxes. Then when you sort your items by fruit, each group will be just one fruit, and the summary will be total of # boxes for each group (ie fruit). If you want results that are more dynamic than that (ie don’t require the sort/preview), the only way I know how is to have yet a third table that is called “Fruit” and matches items by fruit::fruit=item::fruit. In fruit you would have a calc that =sum(items::#boxes)

Alas I do not have fmp Advanced. I don't really get why they don't just make all the versions advanced so I'm stuck with the version we have which is the basic (we're still all on 9). Oh well.

I have removed all unnecessary TOs from my data file and only have those that are called on via calculation. I've deleted all scripts and valuelists from the data file, except for 2 VLs that are called in data file calcs. I have a bunch of valuelists in the interface file that call on fields from data file - should I move those VLs back to the data file and delete form interface file? I was thinking they are part of the interface and as such should be in interface file, but perhaps not... My file only calls on 2 related files, by file:filename.fp7. I've removed all calls and relationships to one of the 2 files during troubleshooting, and no change to performance. I've removed all calculations, summaries, sorts with no change to performance. My only solution for the one super sticky table so far is totally changing the schema to rely on related record creation order and pre-creating all related records. I still keep all the same calcs, summaries, sorts and what not. Now entry is quick but I end up with 60,000 records in my related table instead of 2,000. However, I still have slower performances throughout the database when it comes to simply navigating through records. One basic layout with very few portals is one of the slowest to click through records (using the little fmp index card icon). All I can think of is that it's one of the tables with the most records, but as there are absolutely no complex calcs or summary fields in that table I'm a bit stumped as to why that would be. I also have some scripts that are popping dialogs/bugs that do not occur in the integrated file model. Since none of these issues were happening in the integrated file, I am left with the conclusion that external data files significantly impact performance - at least when you did not develop with the model in mind. Perhaps if you develop with that model in mind you can adjust for performance along the way. As is, taking a complex file that works great and turning it into a separation model just does not seem to work!

Yes - if you want to move them into a brand new table: import --> file/new table. This will keep calc definitions / I think any ref to related field will appear so long as the table exists in new file. Else you have to re"link" those in the calcs. No - if you want to move them into existing table.

In your script, you can also capture errors so they don't display. In this case you can catch the failure to import and set it to try again. If it fails again you can give user an alert that perhaps something is wrong with the file (or what not - if you have IDed what the issue is). Embedding media is not a good solution if you are expecting a lot of media. Filesize can become an issue.

Sorry I did not check on this again. The question in your file does not match the question on the forum - and setting $$Select to tutor::peopleID and student::peopleID to $$Select are working (when a student portal row exists to click on). Is it that you are surprised that you cannot click to assign $$var to empty student::portal row? This is normal, as the student::peopleID is the related field, it "autoenters" into the related tutors::peopleID (which since you are in "turoring" will be from the first tutor record related to tutoring). You cannot have data entry into this field from two different "angles" at once. If you place student::peopleID onto your student portal and manually try to enter into it you will get the same error. As the record cannot create that way, there is no peopleID field to change in that row so $$var does not get assigned. With the existing schema, you would need to create student record in "Assign $$var" script before assigning $$var. You could do that with a set(field) - any other field than people::ID. Just add "set(student::someotherfield):value script step before your set(student:peopleID) script step. [addendum: wherever I wrote "student" please read "contact"]