I have a bit of a problem with a third-party custom DLL holding open some tables between operations.

Pseudo-code:

DECLARE VFPWCSettle IN eVFPWnetCard AS VFPWCSETTLE STRING @, SHORT @, STRING @, SHORT @, STRING @, STRING @
SCAN FOR whatever
  ReturnProperty = VFPWCSETTLE(@HOSTMESS, @TRANSOK, @COMMERROR, @LRCERROR, @BATCHREF, @CONFFILE)
ENDSCAN

My problem is that the DLL appears to be opening a table exclusive and does not seem to be closing the table during each pass in the SCAN loop - so there are filename collisions introduced by the DLL and there are read-only file contention issues during the SCAN.

If there is a way to RELEASE the DLL so it releases the table I might be able to just re-initiate it on each SCAN loop... but I'm unsure how to do that. I'm doing some testing of that concept now...

I don't have the DLL source and the business logic is complex. So far, the best thing I can think of is to call my own wrapper program to perform one operation, return the results to the calling program (or shared table) and QUIT... waiting to be called in the next SCAN loop. Of course, it will run more slowly and there might still be contentions if more than one of my webconnect instances happen to call the wrapper.

Suggestions would be helpful.

OK - I just found that I can use FoxPro's CLEAR DLLS against the list generated by ASCAN. By doing this within the transaction loop, I can avoid the EXCLUSIVE OPEN issue.

Now I've just gotta get the logic working without being able to peek into that DLL... Yech!

Can you see the table in your data environments? VFP DLLs are weird if loaded from within FoxPro in how they share global memory and state with the host VFP process and it might be that the table is visible to your application and you can then potentially close it.

+++ Rick ---