comment

What might help is (1) a screenshot of the message and (2) a detailed explanation of what you were doing immediately before it appeared. "I get to a file in the DB with a PDF in it" is too vague. You can choose Preview to be the default application to open PDF files on your system, as explained here: https://discussions.apple.com/thread/7883441 However, your solution may be overriding this choice, for example by using AppleScript.

I think it's the same question. It's all about how to handle a many-to-many relationship. And the answer is the same: you need a table of Departments, one table for the technicians and a join table for the assignments of technicians to departments. Have a look at the attached demo. It shows a textbook implementation of a many-to-many relationship. Note that it is symmetrical: you can assign staff to a department or departments to a staff member, with the end result being the same. Assignments.fmp12

XSLT can be tricky - but for the purposes of exporting from Filemaker you only need a small fraction of it. After spending an hour or two with a tutorial you should be able to handle most cases.

Didn't we discuss this already? https://fmforums.com/topic/104920-technicians-departments-responsibilities/?tab=comments#comment-475077

A record's body will always have a fixed height in Browse mode. You can view "a stream of multiline records" without a web viewer using a summary field defined as List of [some field] or a calculation field using the List() function to show data from related records. However, you won't be able to do much beyond simple viewing. Although it is possible to detect a click in the field and calculate in which record it occurred, it is a lot of work and the result is substandard UI.

A field is formatted on a layout, not in a table. Add the field to your layout in Layout mode, and format it the way you want. If you added it only using the Modify… button in Table view, you won't be able to format it.

I don't think that's the problem here. The nodes in my test.xml ARE in the same order for every ROW. And you can certainly change that order to anything you want (the simplest way is by changing the field order when exporting).

That sounds like you're not working the InDesign end correctly. The thing that puzzles me the most is that you say you are able to make it work with data from Access - but you're not able to tell us what the difference is. I can help you with getting the export from Filemaker to conform to any format that works for you. But I cannot help you with finding out what that format needs to be.

What exactly does that mean? IIUC, you're supposed to map the input to placeholders in your InDesign document. What's preventing you from putting the info where you want it?

This is starting to get weird. That XSLT does not make any sense and it's not possible you have managed to get anything useful out of it. I have attached an XML document to my previous post - you may have missed it. Please see if you can import it.

I am afraid these screen shots are not telling me anything useful. Now that you have posted the raw XML export from Filemaker, we know what you're starting with. We still need to figure out what you want to end up with. This is what I asked for when I said: Since you say you have managed to import the data from Access: what does that file look like, just before being imported into InDesign? -- Another question, which could shorten this process: are you able to import the attached file? test.xml

Is your portal filtered? If not, the problem becomes "how to count related records" and can be solved by a calculation field in the parent table = Count ( ChildTable::Matchfield ) or by defining a summary field in the child table and placing it on the layout of parent. If the portal is filtered, you can place the summary field in a one-row portal that is filtered using the same filtering expression. Only if the portal is filtered AND you need to use the count of shown records in a further calculation, you would need to use the GetLayoutObjectAttribute() function. But in such case it might be more appropriate to filter the relationship rather than the portal - IOW, work purely at the data level.

Try exporting your data as XML using the FMPXMLRESULT grammar. Then open the resulting XML file in Filemaker. If the export was successful, it will be converted into a new FMP file containing all the exported fields and their data. However, all schema components (calculation fields, relationships, scripts, layouts etc.) will have to recreated. If your original file has additional tables, export each one separately and import them into the new file while selecting 'new table' as the target. Resist the temptation to copy/paste anything directly from the old file to the new one.

I am not sure what exactly I am looking at. To move this forward, I suggest you do the following: Enter some dummy data into your FMP file (if necessary, use a copy of the real file). Make sure you have at least two records; Export the fields you need as XML, using the FMPXMLRESULT grammar, with no XSLT stylesheet applied; Write an XML document, using the same dummy data, in the format you need for importing. Then post the two files here. Note: I am asking for at least two records, because the files you have shown so far seem to have only one record and no provision for multiple records in their structure.

This is very confusing. If you are trying to export data from Filemaker into another XML schema, then we need to know (a) the structure of your source FMP file and (b) the structure of the target schema. I can't see how any part of the codes you have posted is relevant to this task. As an aside: This is a non-sequitur. The XML grammar used when exporting has nothing to do with the result being "flat" or otherwise. It has everything to do with what can be changed in the FMP file without breaking the export: field names (when using the FMPXMLRESULT grammar) or field export order (when using the FMPDSORESULT grammar).