When did reports go from client side vision objects to gateway side objects?

Working on updating a 7.9.9 gateway to a 8.1.2X gateway.

This gateway has been in production since I think 7.7.X or earlier. It still (in the current 7.9.9 version) uses legacy reporting components to make reports.

I am worried about maintaining this in the future. From one of my older posts I came across again, updating will not be straight forward (Report Viewer component not showing report?).

I am wondering if there is some date I can reference to when it was switched from the vision component for designing reports to the current Gateway level report object that is the current model. I want to push that this is something that really should be updated - they are having other issues with this with regards to these reports and I really think updating would fix this as well as be more maintainable in the future.

If I was able to say these components are 8 years old / Ignition will no longer support them, that would be some ammo to convince people this should be done. Does anyone know when this change happened? I know IA is very good at support but is/will there be some cutoff for supporting legacy components like this (please say yes)

7.8:

Maybe not quite the answer you're looking for, but:
We don't have any plans to remove the support for embedded reporting in Vision. However, all ongoing maintenance for reporting is going into the 'new' reporting engine, so bugfixes, new features, etc are all only going to show up in "modern" reports.

2 Likes

Ok my guess of 8 years is about right, that is when the change to server level objects for reports started.

I think right now, I might be able to and want to blame the current problems not necessarily on the reporting component itself, but on the fact it's all done via the client side of things where I have much less control (and no logs) and people could start running the script to make all these reports and close out of the Vision program. That alone would explain these issues.

Having it as a server object would also allow me as the maintainer to make these missing reports as needed with a simple script, whereas right now we need a user to go to this special window, find the missing report, and remake it that way since all the logic is necessarily on the windows. It would also be hard for me to make any changes to these reports too since the tool is very different. I hope these argument holds enough weight to agree with me that this change should be made.

Thanks for the information

Huh. I thought the client side reporting functionality was already gone. This is the perfect example of technical debt from an unmaintained codebase.

2 Likes

I might make the case internally for dropping it come 8.3, actually.

2 Likes

@PGriffith please do. I would love to be able to say that these things have a definitive end to their life cycle and that they won't be able to upgrade past a certain point without making this change.

@pturmel This thing was poorly designed in the first place imo and it was just built up from that on top of itself over and over. Most of the logic is inside windows, or in the legacy code section. Lot of the logic is like "ok this property change should then change this property which will trigger that other property change event" etc. And about half the logic is in these 500 line SQL Server stored procedures. Just discovered that the original designer had setup audit trails within the Ignition gateway and project properties but then neglected to use system.util.audit and instead had a hardcoded system.db.runUpdateQuery that was always writing into the production database, even for the QA version of the app. The whole thing is just a mess and while I know I can't tear it down and start over, part of me really wishes I could.

It's also by far the largest project I maintain used by over 50 clients over the US. So it can't have downtime and have to plan cutovers, which is fine, but it also means their is (perhaps justified) hesitance towards making what from their perspective might be unneeded changes.

It is the bane of my work existence.