Has anyone seen this?  I've seen it about a year+ ago.  After reporting it to Microvellum they said to just create a junk row and "ignore it".  The problem is, now the bug is back and its picking other rows to invalidate.  Its sneaky, random, and can cause a lot of problems for my drafters.  For instance see below:

Row 81 in Component Drawers subassembly use to be Fifth Drawer Box Bottom Gap.  If I delete that row, the bugged cell (says 61) will overwrite the formula.  61 has no reference, no prompt value override, nothing being forced into it.

The only things being force passed to this subassembly include:
      Is_Division_Left      1
      Is_Division_Right      0

      Face_Options         Drawers

      Drawer_Qty      3

      Left_Bay_Open      0

      Perfect_Grain_Container      #2

      RHB_Custom_ID      B

Anyone have any idea why a Subassembly would force override a value without using Prompt Values?  Here are some other examples in similar Component Drawers FF

Row 87 is Broken.  If I were to delete that, Sixth Drawer Box Bottom Gap would become 0.

Row 94 is Broken.  If that were removed Bottom Drawer Type would become Blank =""

Things I have tried:

      Setting a formula to those cells.  They revert back.

      Creating a new subassembly and pasting the values into the new subassembly.  The new subassembly inherits the illegal cells.

      Moving the subassemblies from a folder in Database Explorer to a new folder

      Renaming LibraryName in Local Product just in case that could affect it.

Its like it needs a new Subassembly Identity, but it keeps pulling from an original place.

I do have a ticket but we cant figure this one out.  It keeps randomly getting worse.  Its affecting multiple "Component" subassemblies.  Any help would be greatly appreciated.  Any Ideas, Tips, Tricks, or things that might be useful to test out.  I'm about out of ideas.

Thanks,

-James