The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

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



asked 23 Nov '10, 12:14

Adam%20King's gravatar image

Adam King
accept rate: 0%


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.


permanent link

answered 23 Nov '10, 12:28

Karim%20Khamis's gravatar image

Karim Khamis
accept rate: 40%

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.

(23 Nov '10, 17:58) Adam King
Comment Text Removed

@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.

(26 Nov '10, 12:52) Karim Khamis
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 23 Nov '10, 12:14

question was seen: 3,301 times

last updated: 23 Nov '10, 12:28