I’m in the process of moving files from Panorama 6 to X. When opening a file in 6 with X, summary records are preserved. But copy / paste won’t respect them. When I used the importdatabase command to append a file with summary records, the summary are imported with the rest of the file but converted to blank records. While you have said summary records are a hassle, just PLEASE allow copy / paste / import to respect EXISTING summary records. I have used them extensively for financial logs in 6 and I’d like to preserve the functionality in X.
I guarantee I have never used the word “hassle” in relation to summary records (or I think anything else in Panorama). What I have said is that summary records are not intended to be a permanent fixture of a database. The intention is that you will temporarily group the database, perform some calculations, perhaps print a report, then delete all the summary records. The summary records should not hang around for more than a minute or two.
I know that long ago some users got into the habit of using the summary status of a record as if it was an extra boolean (true/false) field. This was always a bad idea, and has been officially discouraged for 25-30 years. Panorama X takes this even further - for instance summary records do not have a record ID.
It sounds like you are still using summary records in some permanent manner. This just isn’t supported in Panorama X, and will not be supported. You should not be using the summary status of a record as a data bit. Instead, you need to create an additional field in your databases to hold whatever true/false value you need. All of the permanent records in a database should be data records.
If you want to keep the data in summary records, couldn’t you just export them as a text file, then import them to a “summary” database where they become demoted to data records.
Was hoping things changed since I first brought up the subject in 2017. Then you said “caused no end of difficult tech support problems from people that screwed up their databases.” OK not a hassle. Summary records are great for maintaining daily, weekly, subtotals on an on going basis. In 6 select the most recent date records, save, import with append and update the dates in the appended records to the next date. Works great. Anyway I’ll let this go.
I’ll like to keep the summary records integrated in my journal files. Anyway I’m letting this go.
If you choose to revisit it in the future, with PanX’s new relational featured, the summary amounts could be stored (ala export and import into summary file) in a separate database and linked into the appropriate records for display.
… many paths to the top of the mountain.
One of my files contains over 70K records with well over 1K multi-level summary records, the task is way beyond the effort I’d like to put into developing a relation model with all the links.
I summarize some things on occasion. If I do it often, I make a procedure that makes that summary for me, and then another that removes the summary.
These days, a lot of what can be done with summaries can be done with aggregate(.
Also summarytable(
But weren’t the summary records generated automatically, via grouping? You should be able to recreate them at any time. And your summary records are “stale” - they don’t change when the database changes. That’s why they are temporary, they just represent a snapshot at the time they are created.