>
>That's what I meant with more clean. However, personally all my intermediate tables are stored in the Temp dir, so one crash or more won't hurt me that much. Still I wonder how the OLE/DB do handle this kind of stuff, If I got a 100.000 record report, is it going to be stored in the cachefile or also in a tmp file ? If the latter, the argument does not have much actual value.

If OLE DB returns a large number of records, caching will occur on the disk. However, it will use the system cache, which is automatically cleaned up, even when terminated abnormally.

>
>I see. Personally I won't do this unless VFP is wholly taken out of the reporting process. VFP is much and much better in munging data, so if the report is going to be controlled via foxpro, I certainly will get the data from the database server, mung it in VFP and pass the data onto CR.

That can be done. In my case, the application and the reports never have direct access to the data. That's always handled by my middle tier components. Yes, I know.. I expressed cases for direct access for the reports, but in reality, I don't do it that way. But, I my method is the exception rather than the rule.

>
>I see, but the same as the argument above: I don't see to much value in this *if* VFP still is controlling the reporting process. Moving the data selection to CR might (and will in lot of cases I handle) give you trouble in complex reports where a lot of data munging has to be done. In the sake of consistency I'll do all data handling on the VFP side.

I do my data handling in VFP middle tier DLLs.

>
>And one of the tiers fully rely on ADO ? How about XML ?

All the tiers rely on ADO. XML was not an option before VFP7. I can think of situations when I can't get XML directly back from the database server, which, IMO, still leaves out XML.

>
>However it is nice to know that we can use the alternative of OLE DB for passing data to CR.

Yup.. and it works great.