>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>For example at first I was calling my biz objects to gather data for the reports in for/while loops to get the data, but the performance sucked! Now I am using SQL on the tables directly, which of course is extremely fast. I feel that I have violated n-tier principles. Any guidance is appreciated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So are these VFP tables? I try to avoid SQL calls from the UI, but from the middle-layer I don't see a problem. For instance, in an app I currently am working on, we have SQL calls in middle layer objects, returning ADO recordsets to the UI, and the UI layer is responsible for converting this back to a cursor and calling the Report Form command. The only performance hit is due to the need to move data back and forth from recordsets to cursors under this model. In one report, for instance, the middle layer calls a SQL Server SP to return a recordset; the middle layer converts this to a cursor to further filter the results with a SET RELATION into another key table; the middle layer converts this to ADO to pass it to the UI; the UI converts this to a cursor to run a foxpro report from it. As you can see there's an awful lot of Recordset->Cursor and Cursor->Recordset movement, but I can't think of a good way of avoiding this....

(By the way, my own definition of UI in this case is a little more broad than some. My approach to the middle layer is that it returns x number of recordsets, to whatever calling layer needs the recordsets. It's up to that calling layer to convert the ADO recordset into something the user can look at. In the case of the VFP front end, it runs a foxpro report. It could also be an ASP approach embedding the recordset in a web browser table, I suppose. Or a VB screen calling a crystal report. Etc. I guess if you really want to be a stickler about it, we have a conceptual second-middle layer that is in the same physical memory space as the UI.)