AF should react better to unhandled exceptions from a linked table provider
When an OLE DB or ODBC provider returns an unhandled exception for a linked table to the PI AF Application Service , it would be better for it either handle the exception and not crash, or to log the exception, the linked table name and provider name to the AF logs and stop gracefully.
Sebastien Raposo commented
One way of preventing the crash that was suggested is to have one or many sub-processes managed by the AFService.exe and dedicated for the linked table feature. This way if a memory exception is thrown, the sub-process could be stopped and not the AFService.exe and therefore avoiding an AF outage. There are some drawbacks to this idea. For example, adding a sub-process adds another layer the data must go through before being returned to clients which has some performance implications. If the sub-process where to crash, but AF was still running the linked table data could be outdated or an error could be returned causing considerable confusion for users. Asset Analytic outputs could be incorrect as analyses would still running. Etc...
From OSIsoft's perspective, its more logical to fix the issue upstream, meaning using providers that handle their exceptions properly and don't run into memory / heap corruption issues as these are the most common causes for an AF Server to crash. Handling the symptoms downstream would be ideal, but there isn't a great solution for OSIsoft to implement. The best may be to simply stop the service gracefully with a meaningful error message.