Just in case this might help someone else down the road, I have implemented the following procedure to identify the problematic object:
1. Ran the form, then closed. Datasession was still open.
2. Actually, the datasession stayed open after the program terminated, so released one object at a time until the datasession went away. The objects are listed in the locals section of the debugger, so was fairly straightforward to track.

I now know which object is holding the reference and can work with the lines of code that use this object until the form releases. It's much less code than the whole form in my case.




>Thanks so much for your reply,
>
>At the risk of sounding ignorant, I'm sure there is something that I've introduced to do this, but may not have caught this issue for a while, so it could be among hundreds of changes. Is there a tool or method that I could use to try to hunt down any mal-linked references? Without an error, I'm a bit at a loss how to proceed.
>
>>>I have a rather complex form that has stopped releasing its data session upon closure, which creates open table errors, etc. upon moving on in the program. I know that certain objects can "hang" the autoclose procedure, but don't see any definitive, concise information on how to troubleshoot something like this. Does anyone have advice, or a resource that would explain what types of events can cause this? My form utilizes a couple dozen tables, a couple hundred fields, and many procedures, so trial and error will be tedious, at best.
>>
>>The most common cause of this is two objects holding references to each other. Set up your objects so that if they have references to other objects, they release them at destroy.
>>
>>Tamar