Keeping VFP tables open to be accessed by .Net

[grahamrhind]

After a struggle I have succeeded in creating a VFP 9 dll which can be accessed by .Net coding, and it's working fine.

The issue that I currently have is that when .Net passes a string to the VFP code, the VFP dll opens all the required tables, does the necessary work, passes the string back to .Net and closes itself and its tables. This has major speed consequences when there is more than one string to be processed as the tables are very large.

I'm looking for a way to keep VFP tables open between calls from .Net, or if there is a simpler way of doing this so that tables only have to be opened once and not for each transaction.

Any ideas?

Thanks in advance.

 

[Olaf Doschke]

If your dll is unloaded or the .net object reference to your ole class released, there is no way to keep it's tables open. So the first requirement is the .net app keeps his object reference to the object it created from your dll alive.

And then you would simply not close your tables. Perhaps introduce a method opendata (private) and closedata() (public) and let the .net programmer decide when he wants to close the data. Call opendata() automatically if tables are not used() where needed.

Your observation should be wrong, that the performance hit is due to the tables being large, but it's a performance hit to close and open tables, that's true. It only does not depend on the table size, USE table is comparable to fopen, getting a file handle (plus a bit more, eg validating the table header). And that does not depend on file size.

You may already gain speed by SET TABLEVALIDATE TO 0 by the way.

Bye, Olaf.

 

[grahamrhind]

Thanks Olaf,

This appears to be only an issue because of my non-understanding of how the whole dll thing works and my complete ignorance of .Net, and in the meantime we've established that once the component is opened we can open the tables once in a method and then send as much data as we like to the dll without closing it or the tables.

Problem solved. For the record, (parts of) the data tables are read into a cursor - hence the heavy time penalty.

Graham

 

[Olaf Doschke]

Well, yes, what you said and tablevalidation, which moves to EOF and back for example. But vfp is not retrieving many data just by a use, which I think was the main concern.

Bye, Olaf.