I see why you have a problem, David. Since you're running reports on extremely large quantities of data, then you may not have a choice about the time lag.

One possible suggestion: Store the time when the app begins to sweep for updated data, and put that time in the header of any reports done before the next sweep "Data current to December 6, 2000, 04:27 pm"

Another method which will involve more coding and possibly structure changes in the tables is to have a date/timestamp on each record when it is updated. Limit your data sweeps to updated data only, and then add/upate the Foxpro free tables. You'd need to store the timestamp for each sweep to catch all records updated since them.

HTH
Barbara


>Barbara,
>Ok, let me briefly explain our situation and what I want my app to do.
>
>There are reports and data extracts we cannot get in our accounting system so we have written Foxpro apps to accomplish this. The Foxpro apps connect to the accounting system through odbc. Reports that require an entire quarters worth of data and sometimes even more may take 10 to 20 minutes to run.
>
>To speed this up I thought of having a driver running on another computer continually scanning the accounting tables and dumping these records into Foxpro free tables. Then the Foxpro apps can use the free tables instead to get data from the accounting system; Providing the driver can keep the Foxpro tables up to date. But, being the odbc is kind of slow it may take an impractical amount of time to keep these tables current. Example: If someone changes something in the account system and then immediately runs a Foxpro app it may not see those changes. The app would have to be run later after the driver finished updating the tables.
>
>Thanks for your interest.