Hakan:
New development. I must have misinterpreted the ACE API docs regarding what parameters are only to be used in adsDDCreate101() and adsConnect101(). I was only providing DDPassword= to the former, but not the latter (in the cases where the add was strongly encrypted up front; other cases involved calling the stored procedure sp_SetDDEncryptionType()).
Since we might have some installation that will not use strong encryption and others than will (we're still in alpha testing) I'm passing DDPassword= regardless and I see it doesn't affect non-encrypted .add's (other than a 7168 that gets logged in ads_err.adt that seems not to affect adsConnect101()).
With that in place, I was now able to repeat the test I mentioned in my original post, and stopping and restarting the ADS service doesn't corrupt the data dictionary anymore.
So one concern creeps up: when we have our support techs troubleshooting clients, using ARC with no SE_PASSWORD= setting in place will still risk damaging the database a distinct possibility.
Having the SE_PASSWORD= visible kind of defeats the purpose of keeping the database from prying eyes.
Wondering if there's a better way of not exposing the table encryption password in clear text and have ARC ask for it, just like it does for the .add password itself.
Thanks.