Hola Alex.

I'm doing this right now. It works perfectly. And better, the way we are doing it, your tables will be easily deployed to SQL Server once you decide to, and if you want to.
You can access the tables from either plataform, and insert, update, delete too. It's a nice way to do it, and to migrate applications.

On the VFP side, you can create a .dbc with local views of all your tables. And imagine that in your .NET application you might decide to have different table names and field names... no problem. In the views, change field names and add triggers if needed.

Now, use the DDT to create your tables as you want them in .NET, they won't be deployed to SQL, yet. You can later if you migrate to SQL. This table should match the view precisely. The DDT table (the source of your BO) should have the same name as the view.

After creating your table in the DDT, map it with the BO Mapper.

After this, you need to use a VfpDataSourceItem pointing to the *.dbc containing the view.

Point your BO to the VfpDataSourceItem (using its DataSourceKey property)

In the new upcoming version (1.6.1, we got a pre-realise in the last class in Amarillo) there is a new property called ShouldNativeDbTypesBeConverted. This one needs to be overriden to True, so that the VfpDataSourceItem knows that a SqlDbType.VarChar should really be an OleDbType.VarChar.

Then, if you intend to migrate swap over to SQL Server later, without having to rewrite all of your queries, Ben Chase, from the StrataFrame team, wrote a convertion class (SqlToOleDb) that will convert SqlCommand objects to OleDbCommand objects and replace parameters names with ? and re-order the parameters, if necessary. You can have it if you decide to use it, just let me know.

On the other hand, if you plan to keep the database as VFP, or just rewrite the database structure when you migrate to SQL Server, there's no reason to use this class. You can only create the commands as OleDbCommands to begin with. Translating them adds extra overhead that isn't needed unless you're planning on swapping.

I can send you some screen shots of where and what to do if you need, just let me know.

Hope I could help you, Alex.

Ivan




>Hola Ivan,
>
>Thank you for the tip. I bet using UDP to communicate between processes is very fast.
>
>BTW, I was able to access DBF files encrypted with Cryptor through VfpOleDB! The trick is to tell Cryptor to watch for disk access by Oledb32.dll (not VfpOleDb.dll). So now I can probably do simple maintenance of my tables using Strataframe :)
>
>Next step is to figure out how make the VFP and .NET portions of the app share temporary tables that get updated by the VFP side as the user enters data in the .NET side. Any suggestions?
>
>Thanks for the help,
>
>Alex
>
>
>
>>Hi Alex!
>>
>>Sorry for jumping in, but just to let you know...
>>
>>I know that the developers of StrataFrame have a medical package that still has the older VFP application running within their StrataFrame.NET MDI environment and so when the end-user is running their application, they don't know when a form is a .NET form or an older VFP form. They do this by stripping out all of the menus, status bars, etc. in the VFP executable. Then they wrote a UDP listener that runs in the VFP EXE and another in the .NET application. This is the communication pipe-line between the two disparate EXEs. In fact, StrataFrame has a VFP sample that shows the beginnings of this. So the ONLY interop that is used within the VFP environment is the UDP listener. It was my understanding that they had initially tried using a COM interop to make the VFP forms show up in .NET which turned out to cause a lot of difficult behavior on the VFP side of things as it relates to Windows handles.
>>
>>If you post in the SF forum I am sure that the SF team could give you more direction here, but I know that it is possible because this is how they are currently distributing their medical application until all of the VFP can be replaced.
>>
>>Abraços.
>>
>>Ivan
>>
>>
>>>Rick,
>>>
>>>I know you have lots of experience with VFP / .NET interop so thank you for the response.
>>>
>>>I am calling the VFP component from a Strataframe WinForm and saving the object reference for reuse, but since I restart the darn thing so often several debug sessions open up. Ideally I'd like a VFP development session, a Strataframe / .NET session and at most one VFP debug session if it can't be the same one as the development session. Perhaps a search by the dll "bridge" for a VFP process running in a window with a known title may be the way ?
>>>
>>>Any considerations, suggestions and references are welcome.
>>>
>>>Alex
>>>
>>>>If you're debugging from within ASP or ASP.NET you should let VFP start up a new copy each time because that's what happens with a DLL server. If you truly want to debug your code you should try to simulate the same exact environment that the COM server is running through or otherwise you'll see inconsistent behavior.
>>>>
>>>>IAC, that process is fraught with all sort of issues such as how much data you can pass around (because you have to pass parameters as literals). It's better than nothing (well maybe it isn't <s>)...
>>>>
>>>>Don't throw out the old the LogToFile() (or like) routine just yet <s>...
>>>>
>>>>+++ Rick ---
>>>>
>>>>>Hi,
>>>>>
>>>>>I am implementing a com server to provide access to VFP code from .NET based on articles by Calvin Hsia and Rick Strahl
>>>>>
>>>>>http://blogs.msdn.com/calvin_hsia/archive/2007/05/21/write-fox-code-in-visual-studio-that-interacts-with-your-vb-net-code.aspx
>>>>>
>>>>>http://www.west-wind.com/presentations/VFPDOTNETiNTEROP/VFPDOTNETINTEROP.HTM#Debugging%20your%20COM%20server
>>>>>
>>>>>It has come to the point that SET STEP ON opens the VFP debugger, but each time I run my test code I create a new copy of VFP. I'd like to change the code to use an already running copy if available. In Rick's article there is a reference to another article, by Maurice de Beijer who provided the original idea, but it depends on storing the hwnd value of the design time VFP on disk.
>>>>>
>>>>>http://www.theproblemsolver.nl/aspdevelopmentanddebugging/index.htm
>>>>>
>>>>>I wonder if there is some way to cycle through all windows and pick it up automatically, perhaps knowing the title or some other trick.
>>>>>
>>>>>TIA,
>>>>>
>>>>>Alex