Minitab macro error on incompatible column types: partial writes and retry safety

Short answer

Validate before combining, and never let the combine operation be the first thing that touches the real worksheet. A pre-flight check on column count and type, followed by a staged copy that is discarded on failure, gives you both a clean failure signal and a retry that cannot duplicate rows. Leaving the failure to the Session window and continuing is the option that makes retries unsafe.

Why a failed APPEND or STACK is not a rollback

Minitab's macro language has no transaction or rollback semantics. Commands execute in order and their effects on the worksheet, constants, and output persist. So when a combining command hits incompatible column types, everything the macro did before that line is still applied. Two consequences matter for retry design:

• Rows or columns added earlier in the run remain, so a second run can duplicate them.
• Column creation behaviour depends on the command and its options — some commands add a new column, others overwrite an existing one — so "just run it again" is not a defined operation.

Whether lines after the failing command still execute depends on the ONERROR setting in effect. That is the single detail that most changes the recommendation: if the macro does not set ONERROR itself, it inherits whatever the session has, and a CONTINUE-style default will let the macro keep going past the error.

The pattern: validate, stage, then commit

1. Check counts and types first. Compare each source column against its intended target with the TYPE function, and compare the number of columns involved. Comparing TYPE(C1) = TYPE(C2) is safer than comparing against numeric literals, because the literal codes are internal and not a documented contract.
2. Set the error policy explicitly at the top of the macro, before any command that modifies data. STOP (or a jump to a cleanup label) is what makes partial failure detectable; CONTINUE hides it.
3. Combine into a staged copy. Duplicate the target worksheet under a unique temporary name, run APPEND or STACK against the copy, and only replace the original after the operation succeeds.
4. On failure, discard the copy and stop. The original worksheet is then exactly as it was, so a retry after fixing the source columns is safe by construction.

# Illustrative structure only - confirm command names, options,
# and IF/ENDIF syntax in your installed version's Help.
ONERROR STOP

# 1. pre-flight: abort before touching data
IF TYPE(C1) <> TYPE(C2)
  NOTE "Type mismatch: aborting before APPEND"
  EXIT
ENDIF

# 2. stage: duplicate target worksheet to a unique temp name
# 3. combine into the temp copy
# 4. swap on success; delete the temp copy on failure

Note the gap this does not close: type codes describe storage, not intent. Date/time columns are commonly stored as numeric with a display format, so a code comparison can pass while the values are still semantically incompatible. Treat the pre-flight check as a filter for the common case, not a proof.

Detecting partial failure from a caller

Minitab does not give an external caller a documented return code the way a shell script does. In practice the caller has two signals: the Session log text, and a sentinel the macro writes itself — a NOTE line, a constant, or a small output file — placed only after the combine step succeeds. A sentinel is more robust than parsing error wording, because the exact wording is version-dependent. Also remember that rolling back the worksheet does not roll back constants, global storage, or files the macro wrote; if the macro touches those, the retry plan needs to cover them too.

Verification before you rely on it

• Build a throwaway macro that stages a copy, sets the error policy, then deliberately appends a mismatched column. Confirm the Session error appears, that execution stops, and that the staged copy is the only thing left behind.
• Confirm the original worksheet has no extra rows or columns afterwards.
• Add the TYPE pre-check and confirm the macro exits cleanly with no error and no worksheet change.
• Repeat on each Minitab version you support. ONERROR behaviour and the TYPE function are long-standing, but default error handling and exact messages have varied across releases.

If the macro still writes partially, the missing detail to check is whether ONERROR is set inside the macro or inherited from the session — that determines whether lines after the failing command ran at all.