Adam,

This sounds like a bug. Executing STOP EXTERNAL ENVIRONMENT should never be a necessity. You would only make the call if you wanted to free up some resources.

For example, both the JAVA and CLR external environments are database "scoped". That means that there is only one instance of the JAVA VM or CLR External Environment running per database. Executing STOP EXTERNAL ENVIRONMENT in either of these cases only frees up the connection class loader in the case of the JAVA external environment or the application domain for the connection in the case of the CLR external environment.

The C_ODBC*, C_ESQL*, PHP and PERL external environments are connection scoped meaning that there is one instance per connection (but only if the connection is using one of these external environments). Executing SOP EXTERNAL ENVIRONMENT for a connection scoped external environment will in fact shut down the external environment process for that connection.

As you can see then, executing stop external environment for a database scoped external environment frees up a little bit of resources but not much. However, executing stop external environment for a connection scoped environment frees up a large amount of resources since an entire process is shut down.

BUT, it is never necessary to explicitly execute stop external environment. All environment connection scoped processes and database scope resources are automatically "stopped" when the connection is closed. Hence, what you are seeing is a bug and needs to be fixed. Can you, therefore, open up a bug case and submit a repro to us. We will then try to reproduce the problem in house and get the bug fixed.

Thanks.