Hi Ben,

The VfpDataSourceItem would be best if you just need pull data from the VFP database, right?  Does FillByStoredProcedure mean you make a call to a prg that is visible from the VFP database and and data is brought into the business object?  I need to see code for FillByStoredProcedure and ExecuteStoredProcedure() to understand better. Please explain what you mean by "we generally use UDP across the loopback if we need cross-process communication". I thought it may be possible to run locally a "shadow" VFP executable that communicates with Strataframe via some DBFs in a local directory.  What do you think?

Thank you for the answer.  Alex

We have a VfpDataSourceItem that can directly talk to a VFP database.  However, if you want most of your calculations to be in VFP, when you'll most likely want them to be in stored procedures in the dbc or in .prgs that are visible from the dbc.  Then, you can use the BusinessLayer.FillByStoredProcedure to retrieve the values from the sprocs or the DbDataSourceItem.ExecuteStoredProcedure() method to call sprocs directly.  Other than that, if you need to interface with VFP, you'll need to write some sort of COM or use some sort of cross-process communication; named pipes are ugly in VFP, so we generally use UDP across the loopback if we need cross-process communication.

I am planning a time and attendance app as a sister product to our current payroll app.  The latter one was developed with VFP.  Because of the complicated labor laws here both applications require a lot of data massaging (SELECTs and more SELECTs), for which VFP is ideal.

On the other hand, we are evaluating using Strataframe for the front end to ease into your world.

The question is, how should the application be layered to take advantage of Strataframe facilities yet place the majority of the calculations in a VFP component?  As user enters data and calculations are performed by the VFP layer, how would the data be shared between the layers?

TIA,

Alex