Thanks :-). But honestly, I was only speaking in terms of SQL Server's CLR host / SQLCLR in terms of thread-safety issues. There is a single App Domain used for all sessions / SPIDs accessing a particular Assemby in SQL Server so static, class-level variables are shared among them. Console apps and Windows apps use a separate App Domain per each instance of those apps so static, class-level variables are not shared across users / processes / instances of the app. So, I was just warning that IF your code could be called by more than one Session at a time, that could certainly be prone to error, though not guaranteed to be a problem (hence the additional testing needed).

Again, the main concern for loading System.Management.dll is, even if it loads now, Microsoft can change it to a mixed (MSIL and C++) assembly, making it unloadable into SQL Server, which means you would have to scrap this particular SQLCLR code. Of course, that day may never come, but it is a risk to factor into any decision making process.

Regarding the xp_cmdshell idea: I generally use SQLCLR as a means of avoiding xp_cmdshell, but in this particular case it does remove that risk of System.Management.dll potentially not working in the future.

Also, while doing 7 substrings should work every time, there is always a chance of something going wrong with text parsing. Using XML as the format at least removes one point of failure from the process. Slightly bulkier, but a lot more reliable / less brittle.

No problem. Glad I could help and I appreciate the offer :-D.

Take care, solomon...