Export-Excel -TableStyle resulting in file errors and the style being not applied #1725

Activity

1. dfinke

   self-assigned this

   on Nov 5, 2025
2. dfinke commented on Nov 5, 2025

   

   dfinke

   on Nov 5, 2025

   Owner

   More actions

   I can't repro

   
3. jamesrudolph commented on May 22, 2026

   

   jamesrudolph

   on May 22, 2026

   More actions

   I just encountered this issue which led me to here.
   I then tried to reproduce the above issue and was also unable to.
   Then, when I tried running my own script again, it worked (no errors when opening in Excel afterwards). It seems like once you open the corrupt workbook and save it, future overwrites no longer have the issue.
4. dfinke commented on May 24, 2026

   

   dfinke

   on May 24, 2026

   Owner

   More actions

   could be a "heisenbug"

   😄React with 😄1Reacted by Mike Crowley
5. Mike-Crowley commented on Jul 29, 2026

   

   Mike-Crowley

   on Jul 29, 2026

   More actions

   Reproduced, root-caused, and opened #1745 with a fix.

   Why it seemed random: the corruption never happens on a fresh file — it happens when the export runs into an existing file (a regenerated report). Running the issue's exact snippet twice against the same path reliably produces the "We found a problem with some content" prompt; running it once against a new file is always fine, which is why @dfinke couldn't repro.

   Two illegal states get written on the second run (confirmed by inspecting the sheet XML and by Excel refusing to open the files under COM automation):

   1. Two overlapping tables — with -TableStyle but no -TableName, each export added a new table over the same cells, so run 2 stacked Table2 on top of Table1.
   2. A table plus a worksheet autofilter on the same range — e.g. an earlier -AutoFilter export leaves a sheet autofilter behind, and the next -TableStyle export lays a table over it (a table brings its own filter; OOXML forbids both).

   Excel repairs the file by stripping the broken table parts — which is exactly the "style not applied" you saw. It also explains @jamesrudolph's observation that opening and saving once makes future overwrites work: the repair removes the leftover state, and the next overwrite starts clean (until it happens again).

   #1745 makes repeat exports re-use and update the existing table (and clears a clashing leftover autofilter) instead of stacking new parts. All the overwrite scenarios above — plus column growth/shrink and totals-row tables, which could corrupt the file even with -TableName — now produce files that open cleanly in Excel with the style applied, verified against real Excel via COM.

   Workaround until it's merged: add -ClearSheet to the export, or delete the file before regenerating it.