>I'll probably get fired so saying this, but my CIO has laid down the law saying we can no longer use a summary table to get data about our members and, instead, we need to go to the "Master Data" tables.
>
>We have almost 200,000 members and we have a lot of date sensitive layered data about the member in many different tables. Typically, we want to get the most recent layer data item like their current address - not their address five years ago.
>
>We have a VFP table and a VFP process that summarizes some 150 fields worth of data into a summary table for the members. The process takes over an hour to run.
>
>So, instead of one stop shopping using the summary table the CIO says we have to go to each history data table and pull the max address or whatever.
>
>I don't see the advantage of this approach other than it will slow things down and make the code more complex.
>
>Opinions?

The code should not be more complex, you just need to create a view that brings the current data, and the advantage is that then you always have the current data and not last night's snapshot. You can create the view with exactly the same structure of the VFP table, so changes in code will be minimal, as once you got the data from the view, you can even set it's alias to what you already were using, so then only hard part is getting the view right...

[Update]

I've done this last year with a couple of very complex applications, as the new system was very different to the old and in SQL (in the old system we've captured data thru serial ports, diskettes and other stuff), the changes I've done after creating the views were minimal!