When did sp_OACreate et. al. become deprecated?

Question

I had an issue on an instance of SQL Server I'm supporting and many of the Stack sites have information on these features, but most of them basically say "Don't use those; they are deprecated/buggy/leaky". I'm going to try to implement work arounds for my specific issue, but my question is when did features such as sp_OACreate and sp_OAMethod become deprecated? I have to explain this to my Sys Admin and boss in order to justify a rewrite and I haven't come across much just by Googling (although perhaps my search terms are poor).

Answer 1

While I have been unable to find any official notice of deprecation for the OLE Automation stored procedures (sp_OA*), I believe they are generally regarded as deprecated as of the release of SQL Server 2005. Extended Stored Procedures, on the other hand, were officially deprecated as of SQL Server 2005. Both of those features were obsoleted by the introduction of the CLR Integration feature (i.e. SQLCLR).

When features become deprecated, they are listed in the following documentation:

Deprecated Database Engine Features in SQL Server 2005

That link takes you to the SQL Server 2005 version of the document. You can use the drop-down towards the top to check other versions. No version seems to list either "OLE Automation" or "sp_OA", so it would appear that the feature is not officially deprecated.

Yes, you heard correctly that the OLE Automation stored procedures are buggy and leaky (or at least have been at various times / service pack levels). They are less secure than SQLCLR (the "OLE Automation Stored Procedures" feature is either enabled or disabled; there is no control over who uses the feature if enabled, or how it is used, both of which are controllable -- to a degree -- in SQLCLR).

Also, as far as I have seen, the OLE Automation API (i.e. COM) has not been updated to work with any datatypes introduced as of SQL Server 2005 (i.e. MAX types, XML, DATE, TIME, DATETIMEOFFSET, CLR types, etc.).

You should be using SQLCLR instead of sp_OA* stored procedures for any new code. For existing code that is working, it is probably fine to leave it as is. But if that existing sp_OA* code should break, then it would be better to rewrite as SQLCLR instead of trying to get the sp_OA* approach working.