Upgrading from 10.1.400.0 to 10.1.600.0 - Custom Reports Fail due to data sets being invalid

Hello,
Currently I have built a test environment that replicates my production server that is currently version 10.400.16. In the hopes of upgrading to 10.1.600.13. With that being said I was able to upgrade the test server and users have been able to login in and test for awhile now. But one of the issues from the upgrade that has been leaving me stumped on how to resolve it. Is that when users navigate to “invoice entry” and select a custom report style, and select to print the custom invoice. The custom report errors out as so:

image

Detailed Info:
-Database is a restored production backup
-Application server configurations are same as production
-Report server databases were copied over with encryption keys and report server has all the reports
-All standard reports print successfully, its only the custom version of the standard reports fail

Assumption:
-Since standard reports are apart of the base code, the conversion workbench recognizes these reports need updating. But the custom one’s are separate?.I wonder if its possible that when you upgrade to a new base version, you have to rebuild your custom reports? As I know if your in the report style and click “data sync” it overwrites the changes you have made and I don’t want to do that.

@Chris_Conn for reference:

Thanks,

From the highlighted error message from the system monitor, this tells me that your datasets have too many columns coming back. Go into the RDD and hide any columns or labels that you don’t need.

2 Likes

Iv seen that solution on several posts. But this is an exact copy from production so I wouldn’t suspect anything from the report that’s needs to be changed. Plus I have no idea what is needed in the custom version for it to run as there are no tracked changes per reports in E10.

I agree with Aaron. Go into the Report Data Definition and uncheck unneeded columns.

This is not the report (RDL).

do you have a separate ‘folder’ for your reports on the test database?
The shared datasource may be looking at the live database folder…

Tyler, it may be an exact copy from production ( 10.1.400 ), but the data definitions were completely redesigned in 10.1.600, so while it may not be an issue for you now, it will definitely be one in 10.1.600 (as you’re experiencing).

1 Like

@hmwillett Thanks, I will take a look at the RDD and make a few changes.

Tyler, I spent a lot of time in the DD unchecking unneeded columns, trying to get them to work in SSRS without error; I did not have much success. After eliminating the max 1024 column message, I would get an object reference error. There were too many changes between forms to try to fix them, I ended up rebuilding them from the system forms. For example, we have many changes in the ARForm, Epicor eliminated half of the .rdl’s associated with the Invoice; datasets were also named differently. You’re time will be better spent redoing the forms with your changes.

1 Like

@brad_mu So every base upgrade we have to rewrite the reports? Seems so painful…

1 Like

Not all my custom SSRS forms needed to be rewritten, but the ones that returned the ‘maximum of 1024 columns’, I modified a good amount and yes I did rewrite these.

Tyler;

We ran into this as well with our upgrade to 10.1.600.13. We had a number of modifications to the AR invoice so basically had to redevelop our modification into the new RDD. We got our service providers forms expert involved and basically confirmed this. It caused about 20 hours of extra work on this form alone.

At a minimum, Epicor should warn users about this. It would be nice if the ability to merge changes into a new RDD was part of the upgrade process but as it stands we didn’t know there were problems until we started testing.

3 Likes

Thanks for the help you guys, I am still trying to update the RDD and if that does not work I will recreate the report. Thanks!