Is the reason you access views and not the tables directly because you want to change some field names and plan to upsize to SQL Server or is it a requirement in order to accomplish simultaneous use from VFP and .NET?

Very helpful information, thanks.

Alex



>>Imagine that a VFP table is being accessed simultaneously by a VFP app and a .NET app. In which way should the .NET app access the table so that it can see changes made by the VFP app as they are commited?
>>
>>TIA,
>>
>>Alex
>
>(Alex, I just posted the same answer over here after I read your question)
>
>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.