I Cannot Copy the Scheduling Failure Details: Causes and Fixes

When the copy button on the scheduling failure dialog produces nothing, another application is almost always holding the clipboard: the copy is attempted quietly, so a locked clipboard fails without any message. EDGEBIC by User Solutions builds the copy text from the same fields shown on screen, so a retry a moment later normally succeeds, and if it does not, the dialog itself still carries everything you need.

This post covers why the copy fails, what the text contains, and how to capture the failure record for a support request without it. It sits with the other run-failure entries in the EDGEBIC troubleshooting guide, and for what the categories mean see what is a scheduling failure category.

The stakes are small but real: a failure list you cannot capture becomes a failure list you have to reproduce, and reproducing it costs a full scheduling run plus the time to notice the same rows again.

What You Are Seeing

A scheduling run ends with the failure dialog listing one or more jobs that could not be scheduled. You click the copy button, switch to your ticket or your email, paste, and nothing arrives. No error appeared in the application, and clicking again seems to do the same nothing.

Why It Happens

Cause 1: Another Application Holds the Clipboard

The clipboard is a shared resource and only one application can write to it at a time. A remote desktop session, a clipboard history tool, a spreadsheet mid-copy, or a screen capture utility can hold it briefly or for as long as it is busy. The copy attempt is made quietly, so a failed write leaves no trace beyond an empty paste.

How to tell: copying from any other application to the same target also fails or behaves oddly at the same moment.

Cause 2: You Pasted Into Something That Rejects the Format

The copy places plain text. A target that expects something else, or a field that filters pasted content, can silently drop it. This is rarer but worth ruling out with one test paste into a plain text editor.

How to tell: the paste works into a text editor but not into the tool you were aiming at.

Cause 3: The Dialog Was Already Dismissed

The dialog belongs to the run that produced it. Once dismissed there is no history screen holding the list, so a copy attempted after the fact has nothing behind it.

How to tell: the dialog is gone and you are working from memory.

What the Copy Contains

For each failed job, the text carries five fields:

Rows caught before the engine ran carry a pre-flight marker. Those are master-data problems: a missing product, an empty routing, an inactive work center, a work center with no machine units or no shifts. Fix them first, because the engine never got far enough to have an opinion about the rest.

How to Fix It

• Click copy again after a moment. A transient clipboard lock clears on its own more often than not.
• Close the application holding the clipboard, typically a clipboard manager or a remote session, then retry.
• Test the paste into a plain text editor to separate a copy failure from a paste-target problem.
• If copying will not work, transcribe the three fields that matter: category, affected entity, and fix hint. Those identify the problem more precisely than a description of what you saw.
• Do not dismiss the dialog until you have the details, because reproducing them costs a full scheduling run.

How to Capture a Good Failure Record

1. Read the header line, which states how many orders scheduled and how many did not.
2. Note which rows carry the pre-flight marker. They are the ones to fix first.
3. Copy the whole list, or transcribe category, affected entity, and fix hint per row.
4. Add what you changed most recently, since a failure that appeared after a master-data edit usually points straight back at it.
5. Attach the anomaly report rows too, if the run produced a schedule, since the grid there can be exported from its own context menu when you need the data in a spreadsheet.

How to Prevent the Round Trip

• Capture before you dismiss. The dialog is per run and there is no way to reopen it later.
• Fix pre-flight rows first and re-run. Half a failure list often disappears once the master-data problems are corrected, and what survives is the shorter, harder list worth sending on.
• Keep a clipboard manager in mind as a suspect whenever any copy in any application behaves strangely.
• Work the categories rather than the wording. Each category maps to a specific action, and the family of causes behind the most common ones is covered in a job will not schedule at all and, for late-stage rejections, a run failed with a resource shift mismatch.