My Import Read the Wrong Sheet Tab: Causes and Fixes

An import that reads the wrong tab, or reports no rows from a workbook that clearly has data, almost always traces to a sheet name in the mask that does not match the tab you meant, not to a fault in the file. EDGEBIC by User Solutions reads one named sheet per mask run, so a renamed, respaced, or reordered tab quietly points the run at the wrong data or at nothing at all.

This post sits in the EDGEBIC troubleshooting guide and is the sheet-selection companion to how to build an import mask and the mechanics in import masks explained.

What You Are Seeing

One of two things. Either the import pulled data, but the values belong to a different tab (a summary sheet instead of the orders sheet, last month instead of this month), or the run finished with zero rows read from a workbook you know is full. Both look like a mystery because the file opens correctly in Excel and a person can see the right rows on the right tab. The import cannot, because it is not looking where you are looking. It is reading the single sheet the mask names.

Why It Happens

A workbook is a set of tabs, and a mask reads one of them by name. The match has to be exact.

• A renamed tab. The supplier or a colleague renamed the tab from one run to the next. The mask still names the old tab, that sheet no longer exists, and the reader falls to whatever it can find or returns nothing.
• Hidden spacing or case. A trailing space, a double space, or a case difference (Orders versus orders) is invisible at a glance but breaks a name match.
• A copy suffix. Duplicating a tab produces names like Sheet1 (2), and a mask that names Sheet1 reads the original, not the copy that holds this week's rows.
• A reordered workbook. If two tabs have similar names and the workbook was rearranged, the mask can hold a name that now matches the wrong sheet.

In every case the run did exactly what it was told. The mask named a sheet, the reader read that sheet, and the mismatch between the named sheet and the intended sheet is the whole bug.

How to Fix It

Align the mask's sheet to the workbook tab, then confirm with one file.

1. Open the workbook and read the exact tab name. Click the tab, note the spelling, spacing, and case precisely. If you suspect a hidden space, click into the rename field and check the length of the string.
2. Set the mask's sheet name to that string. Open the import mask and point its sheet at the tab that holds the rows for the entity you are importing. One mask reads one sheet.
3. Import a single file and read the result summary. The result dialog gives a row count. If it matches the rows you expected on that tab, the sheet is now correct. If it still reads zero, the name does not match yet; re-check for a stray space.
4. If your data spans several tabs, run the mask once per tab, or consolidate the tabs into one sheet before importing. There is no automatic all-tabs read.

How to Prevent It

• Fix the tab name in the file spec. Agree with the source (a supplier, an upstream system, a colleague's export) on a fixed tab name, so a cosmetic rename never silently empties a run.
• Name the mask after its sheet. A mask called "Orders (sheet: Orders)" tells the next planner exactly which tab it expects, so a mismatch is obvious.
• Rename on intake. If you cannot control the source's tab names, make renaming the tab to the expected name the first manual step of your intake routine.
• Check the row count every run. A zero-row or wrong-count summary is the earliest signal that the sheet is wrong. Reading the summary before trusting the load turns a silent miss into a two-minute fix.
• Watch for copy suffixes. When someone duplicates a tab to preserve a version, the copy carries a "(2)" suffix. Point the mask at the tab you actually load from, and delete or archive the stale copy so it cannot be picked up.

If the sheet was correct but individual rows failed, that is a different problem covered in the import said failed rows. If the right rows came in with wrong numbers, see my imported hours came in wrong.