When to call STOP EXTERNAL ENVIRONMENT

[Former Member]

I was wondering if someone could clarify for me under what circumstances it is necessary to call STOP EXTERNAL ENVIRONMENT CLR.

I have a program which crashes SQL Anywhere on database disconnection if this is not called, and wanted to check if this is a something I am doing wrong, or just a bug.

I get an error "iAnywhere.SAClrClassLoader has encountered a problem and needs to close" when the database is disconnected, but only if this is the only DB connection, and only if I have run a SQL statement through this connection which calls an external CLR procedure. The error doesn't occur if I have first called the STOP command.

I am using SQLA 11.0.1.2427.

Thanks

Adam

[Former Member · Accepted solution]

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.

[Former Member · Accepted solution]

Thanks Karim, I have just worked up a quick repro, which thankfully doesn't seem dependent on the entity framework or anything awkward like that, so I shall file a bug now.

[Former Member · Accepted solution]

@Adam. Thanks for the repro, I have verified that it does indeed demonstrate a crash. However, just to rest your mind at ease a little bit, it is not actually the SA server but rather the CLR external environment that is crashing. Hence if you were concerned about possible database corruption, don't worry, the server manages to shut the database down cleanly. The crash within the CLR external environment will get resolved in a future EBF.