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

John, all of my experience up to now is with classic file-server oriented VFP apps. So in thinking about N-tier stuff I'm quite likely to imagine things that don't make sense or have been proven to be problematic. I'm quite open to being corrected.

Are you saying that Crystal (and possibly other report engines) are liable to damage the SQL database? Or is it a performance problem? (The proverbial "query from hell".) What other alternatives to defining views are there?

Do folks ever maintain a replicated database just for the report engines to play with?


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

Check.


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

Thinking about my current main app and how it might change with N-tier...

I have a search screen where the user can fill in fields to select records. I build a SQL SELECT statement and execute it to produce a cursor. The cursor is then displayed to the user in a browse.

With the hypothetical architecture, the front-end would display the search screen to the user who would fill in the search criteria. The front-end would build a SQL SELECT statement and pass it to the VFP middle-ware. I would be interested in using XML to do this.

The middle-ware component would use SPT to pass this SELECT statement to SQL Server (or another SQL DB) and receive a set of records in return. (I'm fuzzy about how to do this but I know this is standard stuff.)

The middle-ware would then pass the set of records back to the front-end (XML again) which would create a cursor for the user.

Now am I describing this more or less correctly?

The main point I was making about this architecture is that there are many reasons to use SPT to communicate between the middle-ware and the SQL DB and few reasons not to.

Peter



>>
>>John, let me give you a hypothetical architecture:
>>
>>VFP Client or Browser front-end
>>VFP Middleware
>>SQL Backend