THe thing that is taking so long is opening the views based on the large tables.
Even setting NoDataOnLoad to .T. doesn't solve this. When you USE a view using the NODATA clause, or place it in the DE and set NoDataOnLoad to .T. (the same as using NODATA), VFP still executes the underlying SQL to get an empty cursor, but it inserts a clause to ensure that no records are returned. For example, if your view definition is something like:

SELECT * FROM MyTable WHERE

when you use the view with the NODATA clause, VFP issues this behind the scenes:

SELECT * FROM MyTable WHERE 1=0

This way, no records are put into the cursor when VFP opens the view. The bad thing is, it still takes time to run this SQL statement on a large table. I don't know any way around it, but 15 seconds for 2 views based on 200000 or 400000 record tables seems excessive to me. I have forms that have more like 20 views based on tables of similar size, and they don't take that long to open.

Another thing to look at is if you have any Dynamic properties set in the grids on your problem forms. If I remember correctly, the VMP frameork uses a grid based on the table on hte first page, and a p-view for the detail data on the other pages of your form. If the table being opened is of significant size, then the Dynamic properties (DynamicBackColor, DynamicFontBold, etc) can cause slowdowns as the grid evaluates their state for each row.

In the one app that I worked on that used the VMP framework, I had major speed issues with the opening of forms, but most of it was because of framework overhead (DBCX calls, user settings, etc) was taking forever for the form to start up.



>No, the rowsource for my grids are views and I am using NoDataOnLoad set to True. I have textboxes on the first tab of a pageframe that are bound to a table but that table only has 20,000 records. I have 2 views one based on each of the very large tables.
>