Synchronizing with the 9469 allows sharing of clock and trigger signals between chassis. As such, when you break the link between chassis, you are removing the source of either the chassis sample or reference clock (depending on the sync configuration) and therefore depriving the tasks on the slave chassis of any clock source. If you are simply using channel expansion (a single AI task for all AI channels in all chassis), then this clock and trigger routing happens in the backgroud without need for explicit configuration.
I'm not sure exactly which error is thrown upon disconnect (though it sounds like you've tested it). My recommendation would be to use multiple tasks, rather than channel expansion, but still use the 9469 to share signals. Then, if the 9469 is disconnected, it should only cause problems on the slave task that lost connection. Look for the disconnect error, then reconfigure the problem task to use the onboard clock and restart.
I don't have an example of this right now, but perhaps this KB can point you in the right direction.
Cody A.