Hey all,

We have just implemented FoxAudit, and are having trouble with databases and datasessions doing funny things when adding records. Here's how our application works:

A main SYS.EXE starts up sub-module APPs that create their own global objects. Each sub-module also has it's own DBC. Right now I have it set up so that SYS creates a global oFoxAudit_SYS, and each sub-module crate a global FoxAudit object for its database too.

First off, all stuff in the SYS.DBC works great. I can add, update, and delete records and the auditing works great. But when I get to the sub-module screens (forms that originate from the sub-module APPs), upon inserting records I get the VFP popup asking me where my table is. It says the current database is an entirely different sub-module DBC than the one that should have been open for the current form (we use private data sessions on all forms, and all data access is done through local views).

In stepping through code, I can see that all of the stored procs work fine: one that gets the next primary key, the VFP referential integrity proc for the insert, and then finally the FoxAudit proc. At the very end of the FoxAudit proc the current database and datasession ID are exactly correct, but as I step one more time, I am returned to my form's TABLEUPDATE() command, and the datasession has reverted to 1 (default), and the database has been switched to a different DBC (the last DBC opened in datasession 1 I guess). It is at that point that VFP pops up the dialog asking me to find the right table for the actual insert.

Some other details: This only happens if I am saving multiple records in the table (we use optimistic table buffering on our views). If I let the errors pass, I will see that the first record has been saved, but the additional ones have not. Also, if I then try again to save multiple records, everything goes through fine, so this is only for multiple records and is only for the first time FoxAudit has to do any work.

If I turn the FoxAudit stored proc off by just adding a RETURN .T. at the beginning, all of these problems go away and I am back to having a working system. But I can't really blame FoxAudit since it seems to be setting the database and datasession back correctly before the proc exits. Where is VFP getting the idea to switch back to the default data session when it should be returning to the form's private session?

Other things that still work: If I just access the views and add records, everything works fine. If I just run the form that is blowing up on its own (without being part of the elaborate EXE and sub-APP architecture), it saves multiples just fine. The only thing that doesn't work is when everything is integrated into the full system and the sub-app form tried to do it's thing...

All I can say is, please help! Datasessions already have the ability to drive me mad, and this issue appears to be a doozie. Any and all help would be appreciated.

Thanks,
Joe Kaufman
jkaufman@encompas.com