Hi Peter,

OK, let me carefully refactor this. As to the hypothetical architecture, think long and hard about letting a report engine directly access data. At the least, think about defining views in SQL Server for Crystal to use.

As to middle-ware, you better not have any forms :-)

Middle-ware, typically, is non-visual. As a matter of fact, COM does not support any UI.

To your conclusion about SPT, I would disagree insofar as passing data sets back and forth, which is almost assumable with n-tier component architecture. OTOH, an internal n-tier architecture that was a physical 2-tier might work well that way.



>>Use SPT if......
>>
>>You are dealing with large data sets, are comfortable with T-SQL, and/or have identity or uniqueidentifier fields defined in the SQL Server database.
>
>
>John, let me give you a hypothetical architecture:
>
>VFP Client or Browser front-end
>VFP Middleware
>SQL Backend
>
>In this situation all of the updates and most of the traffic to the SQL Db would come from the VFP middleware. It would probably make sense to allow for a reporting package like Crystal that would access the SQL DB directly.
>
>The middleware would have few or no forms so data-binding is not really an issue. I think we could also imagine that other n-tier components would talk to the middleware and not the SQL DB.
>
>In this case using SPT looks likes a no-brainer.
>
>Do you agree?
>
>Peter Robinson