2022.2 KineticUx - Unable to export to excel, no save prompt

We’ve got users in our 2022.2.8 test environment that can’t get the Kinetic Export to Excel to work. We never get the save prompt! It shows as an active task in the System Monitor, forever. If I do it in the browser with debugging tools turned on, it shows a ‘439 Daily Quota Exceeded’ error, but the EpiCare analyst didn’t seem interested in that.

Anyone have ideas?

EpiCare (case CS0003450660) had me try 64 bit mode and running the client as an admin. I also ran the Office 365 modify/repair/quick repair process, based on a 10.2.x issue we’ve previously had.

Have you clicked on the Notification Bell and looked in the System Monitor | Reports tab?

I have found the browser does not automagically pull down files. I think the Edge Client might do something like that but haven’t tried.

I think someone somewhere said the automagic may come in 2023.X

Mark,

Here’s the client version. Clicking or double clicking on ‘Parts’ doesn’t do anything. No prompt to save:
image

If I do the Kinetic System Monitor, I don’t have any reports, and Parts shows as an active task here too. It’s also not sitting in the Scheduled Tasks tab either.:

When I click on the report, it doesn’t open right away. It’s in my browser download folder.

In my experience (also running 2022.2.8), the Export to Excel command doesn’t generate a task at all.

In the browser I get a file in my ‘Downloads’. (Example is an export of releases list from a PO line)
image

In the client it pops up a Save As dialog.

(I realize this doesn’t help solve your problem, just trying to set an expectation for what should be happening)

To me, that 439 error is clearly an issue…

1 Like

Right. If the System Monitor is running, then I get the pop up too but not if I’m only logged into the browser.

**EDIT: If I click on the link in the description column, I do get the dialog box too.

image

Success, sort-of! Looks like it’s been working all along, but Epicor has been processing ALL the records, instead of the first 200 on the initial page load. We just got an export with Job Tracker.

  1. Open job tracker, get the page to load with the first bunch of jobs on the list view (front page), then click the shishkebab (I want to make that stick! More fun than overflow) and Export to Excel.
  2. You get the ‘Export Successful’ message (which is sort-of lying). All that does is put a row in the notification bar and send it to the system monitor to start processing.
    image
  3. Wait X minutes (5 minutes for Job Tracker for us) for the process to complete in the System Monitor. Job Manager’s export process hasn’t completed yet. I’ll check tomorrow again.
  4. Click on the ‘Jobs’ message in the notification bar again, and NOW we get the prompt to save-as.

It was only 470k records, sheesh! :man_facepalming: This will be interesting if we get users accidentally exporting massive datasets unintentionally. The ‘Parts’ process is still running hours later from the Job Manager export.

1 Like

I think if you put in a filter it won’t do the entire dump, but it will still be more than 200…

Can you try this.

  1. In Job Manager try the Export to Excel. I’m assuming if you click on notification and the record the “save as” doesn’t come up.
  2. Go to another New UI form, i.e. Job Entry, and do the export to excel there.
  3. In Job Entry Notification click on the original export you first did and see if that opens. Does it open now? Also in Job Manager does the notification ‘save as’ open up when you click on the record there.

@afabian - The Job Manager export shows up as ‘Parts’ in the notification bar, while Job Entry & Job Tracker’s export shows up as ‘Jobs’. I’m thinking it’s due to the first column being ‘PartNum’ in the Job Manager export.

Will this experiment work?

My guess is that Epicor is attempting to export our million+ part numbers. Is there a row-limit in place in 2022.2.8 to cap the export? Something with a message box that says export exceeds row-limit would be helpful so folks don’t get an incomplete dataset unintentionally (or bog down the servers - you know everyone will try export multiple times when it doesn’t work!).

@askulte I just tested it and it seems to work. See my attached video

@afabian - Thanks for the video. I just tried that, and it did NOT work.

Did your Parts export show completed in the system monitor before you tried opening it in the notifications bar? My Parts is still active a day later, while the Jobs took 4 minutes to process before it’s ready to open in the notification bar.

We’ve got more partnums than Excel’s 1,048,576 max record limit, so that might have something to do with it.

image

Do you have a large database to try that? Our EOY is uploaded for a different case right now, but that’s 2021.2, so you’d have to update it.

How many records was your Jobs and Parts spreadsheets? Our Jobs is 470k records. Haven’t been able to open parts yet.

@askulte
Yes it shows completed in System Monitor
Unfortunately I’m using the Demo Database and only have 1022 records to export.
I did notice if I keep on clicking on the file in notification that eventually the ‘save as’ box comes up. In my case since I don’t have alot of records it takes a couple of seconds before the save as comes up.

My case “CS0003450660 - Export to Excel not downloading in Kinetic UX on client - 2022.2.8” is getting closed as Working as Designed, submit to ideas.

IMHO, it should work like Classic, which wouldn’t attempt to return all rows unless the user selected that option.

I also think that Epicor should gracefully error out when there are more records than excel can handle. My parts export is still active and running since 5:51pm yesterday, and I’m afraid once we start using the Kinetic UX more, users will try to export to excel without realizing that Epicor is doing the entire table. Then when nothing happens for 10 seconds, users will try again and again, loading up the server with never ending processes which we now have to monitor and manually kill (maybe via SQL if the task gets stuck - that should be a user run conversion!). My 2 cents.

IDEA KNTC-I-3156 created - vote early and vote often!

We can’t take the risk of having users on the Kinetic UI, filling up the app servers with never ending processes, unfortunately. This seems to only apply for exports on tables larger than Excel’s 1.048M row limit, so testing on Epicor’s Demo Database won’t show the same result.

https://epicor-manufacturing.ideas.aha.io/ideas/KNTC-I-3156

KNTC-I-3156: Kinetic Export to Excel - Limit Results To Prevent Frozen Tasks and Overloading App Servers

Please revert Kinetic’s export to excel behavior to be like classic, where it will export the records shown, not the entire table (if it has not been filtered). This will prevent overloading the app server with never-ending processes. Or hard code a max row limit of 1,048,575 records, so it doesn’t exceed Excel’s capabilities, and crash it.

If the user wants the full table, let them check an option to return all records, just the Classic UI.

In Kinetic 2022.2, if a user attempts Export to Excel a landing page grid from a large table exceeding Excel’s 1,048,576 max row limit (such as parts, jobs, job manager, customers, quotes, or orders if you have a large database and a lot of history), it will seem like Epicor did not process the request. They get the pop-up that the export was successful, the request goes to the system monitor where it stays as an active task forever (also ignoring the task agent time out setting). Clicking on the notification bar for the file doesn’t do anything, since the process never completed in the system monitor. Then the user will try the export to excel multiple times, since they did not get the save-as dialog box, further over loading the server with a massive process.

This behavior won’t happen in Epicor’s Demo Database, since the dataset is so small.

Further, clicking delete on this task in the system monitor does not delete it. You will need to request datafix ‘FX_Del_SysTaskTables.df’ to kill these stuck tasks every 6 weeks, since datafixes now expire.

Default behavior should not allow ordinary users to crash the app server with infinite duration processes.

Limiting the Kinetic UI export to excel to a max row limit will prevent users from overloading the app servers with infinite-duration processes, ultimately leading to the server bogging down and crashing. If Epicor crashes, shipments stop, leading to unhappy customers and lost revenue. Sales also stop, since the system is down and needs to be fixed by IT.

We won’t migrate our users to the Kinetic UI and run the risk of interrupting our business

Just adding an additional note for others that may run into this issue.
Our System Agent did not have the same value for the Client Data Directory and Server Data Directory values. Once they matched, recycling the App Pool resolved the issues.

1 Like