Indeed, as @SASKiwi requested, if you could please mark your own post as solution, it would be great.
By the way, you should be able to find some evidences in the Windows Event Logs. My 2 cents to your story @cgates .
Just for the record and others coming to this post looking for solution, I will share an experience I had recently. It was on Linux, not Windows, but I think that for all matters, is similar. It could be a possible solution for some situations, specially for those when "nobody did anything to resolve it, and still it is resolved".
When you generate a sas file, being a sas dataset or a sas code/file, you will do it in a certain set of locale and encoding, based on the ones defined in your OS session, but also in the SAS session used to generate the file.
When another SAS session that had a different set of locale and encoding accessed a file generated with their own session, they could access it, and they could save over it. But for files created in different locale/encoding, it could happen one of these 2 options:
- the dataset of file is not even showing up (if the name contains chars from a different charset than the reading session)
- the dataset of file shows up, but cannot be overwritten (if the content is in an unsupported encoding to your session).
The story of this posts makes me think that, perhaps different SAS Foundations - perhaps even from the same machine, as SAS foundation offers different start ups through NLS (National Language Support) configurations - with different sets of locale/encoding generated the issue - but also could resolve the issue on itself once the usage of SAS foundation gets into standards and everyone uses what they should use, with the configuration that is expected.
Bottom-line and long-story short, specially for collaborative environments where people from different countries work together: always mind the locale and encoding of the session, and the outputs.
... View more