I've been struggling, without success, to display in one file a group of summary fields from a related file (count, std dev, avg, et al.) via a portal.
Why do you need the portal? If you can use a list view layout based directly on this table, you can get your sub totals. As you have discovered, you can't get sub totals for each group in your portal. A portal to an intermediate table where you have one record for each group can be used, however, to dsiplay the sub totals for each group.
In terms of the crashes, this is not normal behavior. Crashes are often caused by file corruption and Crashes can corrupt your file. For these reasons, you should run a recover on this file to check it for damage.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
The reason for the portal is that the relationship is one-to-many. To the best of my knowledge, a portal would be the only way to output to a report format that shows the summary data for a record in the one file, for every possible group to which it's related in the other file.
The situation is further complicated by the fact that, to be exactly precise, I must print the report to PDF, and then select, copy and paste the resulting text in the PDF into another web app. So the text needs not only to include all the related summary data, rounded to limit significant figures (FMP calculates averages and standard devs to 16 digits), but it needs to include other descriptive labels and text, as well.
The only technique which has worked, so far, is to store the summary fields as one set of data per group (breakfield) in an independent table, then use the portal to display the related summary stats for whatever groups the unique record matches.
Oh, and I should add that the only technique I've discovered to do the above, is to save the file with the summary data as an Excel file, then delete all duplicates of each group (again, the breakfield) so that what I'm left with is a spreadsheet with a row of unique stats for each groug. Then I import the summary data from the Excel file into the independent, related FileMaker table. (This is all so convoluted, I surely must have my dbase structural concepts screwed up somehow!)
Hope that's not too vague.
describing your tables and relationships in detail or posting a screen shot of the relationships would help suggest the best option. I don't think you'll need to copy and paste from a PDF if you set this up correctly.
A few observations:
There's a "group by" option that can be used when exporting data that omits the need to then delete all the individual records.
A one to many relationship does not necessarily preclude using a summary report to report the data. There are ways to pull up just the specific records in the many table via Finds, go to related records--sometimes with a constrain found set to further filter down the records. The exact method to be used and how practical an approach this is depends on the details of your database design.