EasyCatalog error messages: what they say, and how to clear them
When a message pops up in the middle of production, the question is not what the words mean: it is knowing what it has detected, which step clears it, and why it will come back if you only apply the step. This page gathers the messages I come across most often in training and support, each with its exact wording as displayed.
How to read this page
Each message is given in its original English wording — the one you paste into a search or send by email. Under each one: what the message actually detects, the EasyCatalog module that raises it (useful: it tells you where to look), the step to take, and the trap that brings it back. None of this is a rewrite of the 65bit documentation: these are production situations.
“A field with this name already exists”
What the message detects. A field with this name already exists in this panel. The message is raised by the EasyCatalog interface itself, so it does not depend on the data provider: you will see it with a delimited file as well as with an Excel workbook or a relational source.
The fix. Choose another name for the field.
The trap. You look for the clash among the calculated fields you just created, and it is elsewhere: the name of a custom field clashes with the name of an imported column. So check the full list of columns, not just the custom fields.
“The fields selected must be from the same data source”
What the message detects. The selected fields come from different sources, and the requested operation only applies to fields from one and the same source. You meet it wherever a panel exposes fields from several origins — typically a combined data source.
The fix. Restrict the selection to the fields of a single source, then repeat the operation source by source. The prefix carried by each field tells you which source it comes from; it is the most reliable clue on screen.
The trap. On a combined panel, a selection made with the keyboard or with “select all” picks up fields from both sources without you noticing. The message then looks arbitrary, although it is accurate.
“The document does not contain any intersecting page guides”
What the message detects. Raised by the Pagination module. In guide-based pagination, EasyCatalog drops the template at the intersections of the page guides. Without guides that cross, there is no drop point: pagination has nowhere to start.
The fix. Place horizontal and vertical guides so that they cross at the required positions. Better still: place these guides on the master pages. Every page created then already carries them, and pagination no longer stalls.
Pagination stops after the first page?
Same issue, seen from the other end. Guides placed on a single page do not carry over to the following pages: the first page finds its intersections, the next ones have none. And guides that do not cross — horizontal only, or vertical only — produce no intersection, hence no drop point, however many there are.
“A data source with this name already exists” / “A panel already exists with this name”
What the message detects. A panel with this name already exists, and EasyCatalog refuses to create an identical second one. The two wordings describe the same situation in two different modules: the first comes from the file data provider (delimited, Excel), the second from the Relational module. The fix is the same; which one appears simply tells you which route you took.
The fix. Either overwrite the old panel if it is no longer used, or choose another name for the new one.
The trap. Overwriting deletes the whole configuration of the old panel: field options, key, subsets. It is not a merge, and there is no undo. Also, a similar message says something quite different: “A data source of the same name is already open” means the source with that name is still open. Close its panels — including hidden ones — before trying again.
“The 'Field Prefix' field cannot be empty” / “The 'Key Prefix' field cannot be empty”
What the message detects. You are configuring a combined data source, the one that joins several sources without SQL, and a mandatory prefix has been left empty. The two settings concerned are “Field Prefix” and “Key Prefix”.
Why it is mandatory. The prefix tells apart the fields coming from each source. Without it, two columns with the same name — a “Description” on each side — collide, and the combined source no longer knows which one to use. The key prefix plays the same role for keys. An empty prefix is not refused for the sake of the interface: it is the only thing that prevents the collision.
The fix, and what it commits you to. Enter a short, meaningful prefix for each source — the source name or its initial. And keep it identical from one rebuild to the next: the prefix becomes part of the field names, and therefore of the templates already placed. Changing it afterwards renames the fields, and the items already placed in the document can no longer find them.
“Group name is invalid or contains illegal characters”
What the message detects. Raised by the Relational module. The group name entered contains characters EasyCatalog does not accept. Not to be confused with “The “Group Name” has not been specified.”: an empty name and an illegal name are two distinct refusals.
The fix. Rewrite the name without special characters: letters, digits and underscores are enough.
The trap. It almost always comes from a copy-paste out of a spreadsheet — non-breaking spaces, curly quotes, invisible line breaks. And when the name comes from a field value, it inherits the characters of the source data: the problem then lies in the data, not in the typing, and fixing it on screen will not survive the next delivery.
“Invalid unique key” / “Invalid codification key”
What the message detects. The chosen key does not identify a single record: at least two records share the same value. Both messages come from the Enterprise module, the one for enterprise data connectors; you will not see them on an ordinary file source.
The fix. Choose another field whose value identifies a single record — or build the key from several fields whose combination is unique.
This choice cannot be undone
The key commits the whole life of the production: it can no longer be changed on a configured panel. So it must be settled before import. And there is one case that passes today’s check and breaks next season: an identifier recycled from one product to another across collections is unique today, and destroys synchronisation when it comes back attached to a different product.
“Invalid private key”
What the message detects. Raised by the Enterprise module. It concerns the private key of a PIM connector — not a licence, not a serial number. That is the most common confusion about this message, and it sends you looking in the wrong place for an hour.
The fix. Get the private key again from its source, in the channel configuration on the PIM side, and paste it with no leading or trailing space. Check the connector code at the same time: the same module shows “Connector Code:” and “Invalid connector code”, and the two values go together — an error on one is often reported by the other’s message. On a Sales Layer channel, these are exactly the two values to copy: the Connector ID and the Private Key of the channel created on the PIM side.
The trap. A key regenerated on the PIM side invalidates the old one without any warning on the EasyCatalog side: the connector worked yesterday and no longer works today, although nothing was touched in InDesign.
Your message is not in this list?
This page covers the messages I come across most often; it is not exhaustive, and it grows with real situations. Two useful remarks when an unknown message appears.
First, the module that raises the message is information in itself. A message from the Pagination module points to guides and master pages; a message from the Enterprise module to a PIM connector and its credentials; a message from the file data provider to the source and its structure. Knowing where the message comes from rules out three quarters of the leads.
Second, most messages that show up in production do not point to a plug-in defect: they point to data that does not follow the rule it was given. A key that is no longer unique, a column renamed between two deliveries, a character inherited from an export — the message is the symptom, the data is the cause. That is why I advise checking the file before connecting it rather than after.
Check a file before connecting it
A free demo lets you check a product file — duplicate keys, stacked headers, empty columns, stray rows — right in the browser, with nothing to install and without the file leaving your computer. It is the check that prevents half the messages on this page.
Need advice on a specific situation?
If a message is blocking a production in progress, the quickest way is still to look at it together: support is provided remotely by screen sharing, and most one-off blockers are cleared in a single session. If the issue keeps coming back from one project to the next, it is rather a sign that training or a project validation would pay off more than another fix.