AppGini Community Forums

Hi all,

I've been using and updating Plugin tools for a number of weeks now, and I have one nagging problem / challenge at the back of my head at all times, and it concerns best practice for updating plugins - many of my examples / problem areas have been with Summary Reports.

When your database is updated to add an additional column or columns, what do you do with your .axp files in the Plugins/Projects folder?

- Do you place a copy of the existing project with a new filename? e.g. Project20250708
- Do you replace the file with the same filename and an updated schema? Does this cause issues with existing reports? e.g. Summary Reports?
- Does updating the project result in loss of visibility of all reports built with a previous version?
- Do you wipe reports each time and rebuild them each time? I find that reports built on the old data model sometimes disappear and I have to start again.

I'm struggling to differentiate between limitations of the plugin / solution, versus best practice behaviours which avoid issues, and would welcome feedback or advice from those using the tools for a longer time. Anything welcome!

Based on my experience and this earlier post, here’s what has worked best for managing plugins and AXP files, while avoiding common pitfalls:

When your database is updated to add an additional column or columns, what do you do with your .axp files in the Plugins/Projects folder?

Always keep your AXP file updated after plugin use
Whenever you use a plugin (e.g., Summary Reports), it modifies the AXP file stored on the server to include plugin configurations. It's crucial to download this updated AXP file after using a plugin. If you later make structural changes using an outdated AXP and regenerate/upload the app, you risk losing plugin-generated settings.

Do you replace the file with the same filename and an updated schema? Does this cause issues with existing reports? e.g. Summary Reports?

Use versioned AXP filenames if you're making major changes
Replacing the AXP with the same filename is fine, as long as it's the most recent version (downloaded after using plugins). If not, you may lose plugin-generated content. To keep track of changes and maintain a fallback, it's good practice to save dated versions like Project20250708.axp. Moreover, always base new changes on the most recent AXP that includes plugin configurations.

Does updating the project result in loss of visibility of all reports built with a previous version?

No, after DB/schema changes, regenerate and reapply plugin settings
If your schema changes (e.g., adding a column), regenerate the app in AppGini and then open the plugin (e.g., Summary Reports), upload your project file again to refresh the available fields and regenerate the plugin output. This is also when some previously built reports might disappear or break, usually because the underlying schema changed and the plugin can’t find the old fields. That’s not a bug, just a mismatch between schema and config.

Do you wipe reports each time and rebuild them each time? I find that reports built on the old data model sometimes disappear and I have to start again.

No need to wipe/rebuild from scratch each time, unless something breaks
If you've been using the latest AXP and follow the above steps, most reports should stay intact. But if a specific report references a field or table that was renamed or removed, it will need to be rebuilt.

Rest asured Elgaucho, you're not alone. Many users run into these sync issues between schema updates and plugin setups early on. With consistent versioning and careful AXP management, the process becomes much smoother and more predictable over time.

-Saymaad

I love it saymaad!

Some great pointers in here!

After I put this post up, I did go back and review / analyse what was going on with my plugins, and do a bit of housekeeping. I observed a few things:

• If you upload versioned .axp files and create summary reports with a specific one, the drafted reports are saved in that version of the .axp file. If you open a different version of the .axp you will not see the reports.

• I THINK that if your reports are fragmented in this way, and you upload a new .axp to create reports, that when you publish, only the contents of the last published version will be visible. This seems to encourage keeping a single master file, and perhaps renaming the old ones to a previous version build, for example, and if you want versioned backups. That said, I fully assume that your reports will not be visible in the old versions due to the name change.

• Selecting wipe all reports in a version of the .axp creates a backup file with a prefix in the format "1-". Useful to restore reports (which is explained by the Summary Reports plugin!), and for major changes, as saymaad described

• to clean everything up on my end I went through each .axp, saved the settings of the reports I had created, wiped them and then recreated them in one master .axp file - the most recent, without a yyyymmdd suffix. I will check to see if this works consistently for future builds

So I've just done an update - I added a couple of additional columns in my primary table (which drives most of my Summary Reports).

I renamed the existing in the plugins/projects folder from .axp from filename.axp to filename20250711.axp.

I pasted the updated filename.axp into the folder.

I open up filename.axp in Summary Reports. It's empty of all reports.

I open up the freshly renamed filename20250711.axp report, and I can see all the reports that I had previously drafted.

I'm not going to do it right now, but I suspect that if i build a report in the updated .axp, that the Summary Reports menu will likely only show the new report, and not keep the old ones?

Yes, each .axp file stores its own set of plugin configurations. So if you create reports using updated_filename.axp, you won't see them when loading filename20250711.axp, even though they might be structurally identical, but their plugin configuration could vary.

Yes, when you publish from the plugin, only the reports in the currently open .axp are pushed to the generated app.

The Summary Reports menu that appears in the generated app (after you publish) only reflects the reports from the latest published .axp. So you're right, if you build a new report in a fresh .axp and publish, only that set of reports will be visible. Previous reports stored in other .axp versions are not lost, but they won't appear in the app until you re-open that .axp and publish again.

This is why "single master AXP" approach is spot on. Keeping everything centralized and avoid fragmentation.