10.2 to 10.4 conversion (SSRS report error)

We are upgrading our 10.2.200 to 10.2.400 and when testing our custom ARForm we get the error below. The stock report works fine, but I’m not sure what to do to get our custom report working. I’ve looked through our entire custom RDD and all of the queries in the report and I don’t see this field referenced. Any ideas of what I should look for next?

Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Column ‘Calc_IsDraftCopy’ does not belong to table InvcHead.
Stack Trace:
at System.Data.DataRow.GetDataColumn(String columnName)
at System.Data.DataRow.set_Item(String columnName, Object value)
at Erp.Internal.AR.ARInvForm.SetColumnValues(String tableName, DataRow row) in C:_Releases\ERP\UD10.2.400.7\Source\Server\Internal\AR\ARInvForm\ARInvForm.cs:line 5267
at Ice.Core.RptTaskBase1.RunSetColumnValuesProcess(String tableName, DataRow row) in C:\_Releases\ICE\ICE3.2.400.7\Source\Server\Internal\Lib\TaskLib\RptBase\RptTaskBase.cs:line 212 at Ice.Core.RptBase.ReportRowDataWriter.WriteRow(IRow row) in C:\_Releases\ICE\ICE3.2.400.7\Source\Server\Internal\Lib\TaskLib\RptBase\ReportRowDataWriter.cs:line 65 at Erp.Internal.AR.ARInvForm.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:\_Releases\ERP\UD10.2.400.7\Source\Server\Internal\AR\ARInvForm\ARInvForm.cs:line 1286 at Ice.Core.TaskBase1.StartProcess(Int64 instanceTaskNum, String outputFileName) in C:_Releases\ICE\ICE3.2.400.7\Source\Server\Internal\Lib\TaskLib\TaskBase\TaskBase.cs:line 47
at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:_Releases\ICE\ICE3.2.400.7\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 98
at Ice.Hosting.TaskCaller.ExecuteTask() in C:_Releases\ICE\ICE3.2.400.7\Source\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 57
at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:_Releases\ICE\ICE3.2.400.0\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 63
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:_Releases\ICE\ICE3.2.400.0\Source\Server\Services\Lib\RunTask\RunTask.cs:line 592

1 Like

If the custom RDD was part of the upgrade, I might try rebuilding that RDD from scratch.

I would start here. Also, as I’ve recently learned the hard way, if you’ve clicked the “Dataset Sync” button on this style, your report is hosed. Starting over from scratch is the only option.

Okay. Is the standard process during upgrades? We have at least four reports not working: OrderAck, JobTraveler, ARForm, CustSt. Each have similar errors. Dig through and try to rebuild each of these RDDs?

Right. This is where I was trying to start, but I don’t know where the InvcHead the error is pointing to. In the RDD, in the SSRS?

If the conversion broke your report someone probably clicked the Dataset sync somewhere along the way. I am currently in the process of rebuilding our Quote/PO/Invoice/SO forms as a result of my lack of knowledge on the button. You’ll need to rebuild them and avoid that thing like the plague.

Check out this thread where some of the vet’s here gave me a quick clinic on tracing the fields.

‘Calc_IsDraftCopy’ does not belong to table InvcHead

The above field is not in your dataset/RDD. You have to add it to RDD.

Vinay Kamboj

I can’t find the Calc_IsDraftCopy field referenced in the RDD or the SSRS… I’m not sure why the error is being thrown.

Yes, I’ve been warned to avoid that button like the plague and have thus far avoided clicking it.

1 Like

My guess would that the Calc_… field is new in the update, so when your custom RDD was copied from the old version to the new, that new field isn’t in the RDD.

Since your RDL’s are based on the RDD (You did copy them over, right?), they shouldn’t be looking for that new field. But if they have any sub-reports, and the new subs require it, they won’t find it in the dataset.

Were the forms you mentioned (OrderAck, JobTraveler, ARForm, CustSt) in their own folders, in the CustomReports folder on the SQL server? Or did you just create a an RDL and put it in Custom Reports?

For example, the original OrderAck form consists of the following “files” on the SSRS server:

reports\SalesOrderAcknowledgement\SOForm.rdl
reports\SalesOrderAcknowledgement\SOForm_KitComponents.rdl
reports\SalesOrderAcknowledgement\SOForm_OLMscCharge.rdl
reports\SalesOrderAcknowledgement\SOForm_OLMscCharge.rdl
reports\SalesOrderAcknowledgement\SOForm_OrderMscCharge.rdl

The first is what the Report Style points to. The others are subreports called by the first.

A custom verssion of OrderAck should reside in

reports\CustomReports\SalesOrderAcknowledgement\SOForm.rdl

and all the subreports in that RDL should point to the subs in ..\CustomReports\...

If they don’t, then they are referencing the RDLs from the newer version, which are probably looking for the field in question.

We copied our Live to Pilot, then ran the upgrade to the version (10.2.400.x).

A little while later I realized that I hadn’t copied over our custom reports, so I made a solution from live with all of our report styles (when saving they packed up all of the RDL files).

I then imported this CAB file into Pilot, adding all of the custom reports.

NOW, I wonder when I first tried this if I also copied over the pre-converted custom RDD files (do custom RDD files get automatically upgraded in some ways?). If so, I wonder if I can manually run a user conversion on these custom RDD files to double-check before I begin the process of rewriting them.

Rebuilding the RDD’s is probably your best bet.

When I was first doing custom reports, I was doing it “wrong”. I’d just open the original, make my changes and save as a new name (but in the location with the original). Then in Report Style I’d just change the name of the RDL.

This worked, but was a bad way to do it. The new RDL just references the original subreports. The better way is to use Report Style to duplicate the report, setting the copy’s path to be reports\CustomReports\... That will create a new folder under CustomReports with a fresh copy of all the files from the original reports folder (like all the RDLs in reports\SalesOrderAcknowledgment\)

If you update the App, It will update the exist report RDL’s. so if your custom report references the originals, their datasets might not matchup.

Below is a screen shot of the original SOForm.RDL from 10.1.400 and from 10.2.300.
If any of those added fields were used in a subreport, the RDD from 10.1.400 wouldn’t work with an RDL that references the subs provided with 10.2.300.

Thanks. Inside of MSSSRB is there a way to see the path of my subreports? Each time I look at the properties it just shows the subreport name, but not the full path.

‘Calc_IsDraftCopy’ does not belong to table InvcHead

The above field is not in your dataset/RDD. You have to add it to RDD.

Vinay Kamboj

This worked for us!!! Ended up having to add 4 fields total and delete one from the form Query and it worked.

And that is why the report is not working. You will have to build the RDD from scratch. The field would be in the canned RDD if you check. We had the same issue on the invoice with another field on the InvcHead and had to rebuild the RDD.

Vinay Kamboj

But why would custom RDL’s, (made with the custom RDD form the older version) that aren’t looking for the field, error out?

That is the million dollar question. I guess the program that runs the report looks for them or something. Maybe someone here who is more knowledgeable about this stuff can answer.

Vinay Kamboj

My issue was this: after we upgraded Pilot to 10.2.400 I realized that I didn’t have the most recent set of reports in our Pilot /custom folder. SO, I went to Live (10.2.200), created a solution, added all of our custom report styles, and imported this CAB in Pilot. During import I overwrote each RDD file, which must have had some changes during the DB upgrade.

To fix, since the reports were now in the Pilot /custom folder, I simply wiped Pilot and ran the upgrade DB again. Fixed.

Thanks for all the feedback and help. Your answers got my head spinning through the issues until I realized my mistake.