Jockey,
Dan has already answered, also I already stated where an additional cursor can influence further processing, assume you do AUSED and process any open cursor in some way, then an unexpected cursor not from you can disrupt your code. Whatever happens in your scope and is not the documented result or behaviour of a module you use is a bug, too.
For example I wrote database interfaces, classes quite like webservices that had methods like getRecipe(id,"crsRecipehead","crsIngredients"), that'll return cursors and then had the configuration option of tidyup .T. or .F., because additionally to the expected result cursors I might leave the underlying tables of the recipes open or close them. If a user of the interface knows he'll pull several recipes out, leaving tables open will make the whole loop faster.
So it can be useful to leave things open, if they are usable for the next call, but you better make that configurable.
This is not strictly about encapsulation, as that is more about the aspects of code separation and separation of concerns, but it tends to go into this regime. If the next call will CREATE CURSOR xyz again, you don't profit from the left open cursor and you also don't save time closing it, at some time it will be closed anyway.
Another simpler reason is, if you ever debugged code and you have more cursors open than the datasession window can show - even resized, then you're at a point where debugging is harder due to a cluttered datasession. A workaround is SELECT aliasname, if you know the alias name you want to browse, but it's easier with a tidy session, isn't it?
Bye, Olaf.
