Jim B,

>I see a major problem with this behavior for RELEASE. If I have a utility object that is instantiated by my application object and other objects call the application object for a reference, then releasing one reference would release the object and leave an unknown number of objects with no access to their utility object because the references were NULLed.

In my thoughts it should be implemented in the following manner:

- an explicit RELEASE command should release the attached object, maybe accomplished by extra parameters [FORCE]|[NOFORCE]

- if a variable goes out of scope (or an object with references is released) it should work as in previous versions (implicit release).

- if a release method of an object is called. The object *SHOULD* release (aside from the query unload feature).

- If an object is released, all remaining refenced variables should be set to .NULL.

- You can set the default behaviour by a setting SET FORCERELEASE ON|OFF: with the OFF setting it should work as in previous versions

In my opinion this is a enhancement request. I definitely believe that the behaviour of the release method is a design err. Your example of the RELEASE command might indeed be a problem for *at least* existing code. Therefore backward compatibility should be provided.

Are there other black holes we forgot ?

Walter,