Hi Tracy
My appologies for taking so long to respond to your post.

The app is used primarily in remote locations away from networks etc.
So the user comes to the office, selects a large dataset from SQL Server and stores it locally in dbf's on his/her laptop and moves off to a remote location where the data is analysed and manipulated.
The users dataset now in dbfs can be anysize up to many hundreds of MB in size.
Currently the data is viewed in VFP grids and there are no .Net components at all.

What we are looking for is more modern UI controls are are more BI oriented and the really good ones are .Net based hence our need use use these .Net controls with our VFP app and the subsequent need to Interop between VFP and .Net

All data is stored and manipulated in VFP using a lot of meta data to do so. The performance of our VPF data analysis layer (VDAL) is perfect and see not point in .Netting it as this stage.

Currently all UI is VFP based, we want to develop a few new Modules using .Net based controls such as Grids and charts etc. The VDAL will need to provide the data to the .Net Controls, the user will make selections therein, the selections will need to be passed back to the VDAL which in turn will prepare the requested data for analysis and get it passed back to the .Net Controls and this cycle gets repeated over and over.
It is the scope of the users selections, (eg: 1 Region or All Regions) that will determine the size and shape of the data to be viewed in the .Net controls.

Any new .Net code will be developed by ourselves.
We will of course use 3rd party UI controls such as grids and charts etc.

I have noted your comments below re :
1) Eventing,
2) simultaneous shared access to the same data tables,
3) wwDotNetBridge - looks fit for purpose after a fist look

Hope this illucidates things a bit better.

In this matter, We have a lot to consider, evaluate, benchmark and proof-of-concept after considering Yours, Joel's, Thomase's and Graig's posts.

Thanks for your interest so far




> I must be missing something in your requirements.

> Where does the data reside? In VFP tables or in sqlserver? Or elsewhere?
Where is the first point where the data is loaded into user controls? VFP or a vb.net winform?
Is it necessary to display the data (or the modified subset of the data or what exactly) in VFP after vb.net has done something with it? And vice versa?
If you really need for VFP and vb.net to massage the data and both see the results somehow (I'm not clear on your overall goal and requirements) why not have both access the data and use event firing in vfp from .net and vice versa to tell vfp to go out and get the massaged data (or vb.net to do it) itself instead of actually passing back and forth that much data. Can you store the results (whatever vb.net has done with it) to a backend and just fire an event in vfp from vb.net to tell it to go out and get it instead of passing +-200mb of data around?

> Why are passing +-200mb of data back and forth?
Can you be a little clearer on what the goal is and how you expect it to behave?

> Regardless, if you need to throw events in either or both from the other or pass data back and forth, Thomas is correct that the com interop dll must be registered on the machine to use it from vfp (and all the com interop design must be done correctly). It may be easier for you to go with the ww stuff - simpler from your end.

> I guess I though the vb.net piece was someone else's (3rd party) and not yours. Is that the case or are both the vfp and .net pieces something you own and control? That will make a difference in your options.


>