>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.
>
>
>>

Just a thought: Can you put the data into local tables in a "working directory" and then have the .net forms and controls access that data via oledb drivers and then just pass information on the status ( or something to tell vfp to go get the updated data or a path to a new dbf created by .net from a massaged net data set or something) back and forth instead of passing the data itself? .net can create/read/write to .dbf files using oledb. There are plenty of examples out there and others here can assist...

I guess I am still not seeing a reason for actually passing the data itself... I would consider an api middle piece (the com interop piece) that vfp talks to and the .net module can speak to it too -- that way your .net module can be clean from the start and no huge datasets going back and forth...without the direct com interop between the .net module and vfp. When you no longer need it (moved all modules to .net), get rid of the middle api com interop dll. Just tell your .net module what to do (go get the data from here or what filters to use or a query command or whatever) via the api dll and vice versa. You can write the .net module to go get the data via other means as well by passing it a result set in .net as another option or going and getting it via a data access layer or the data access layer does the communicating via a switch and decides which route to take etc - lots of options - so you can get rid of the api com interop piece (or not use it anylonger when no longer needed) later. You can fire events in the api middle piece to tell the .net module how to access the data or have the middle piece go get it and pass it or pass the queries, commands, etc or whatever... This would not be difficult to do a mockup of (proof of concept) just a little time consuming to do the three pieces as a demo.