Hi Robert

Like you, when I first heard this, I really didn't like it, but you really need to forget the idea of having access to the entire *TABLE*. It was all smoke and mirrors anyway. What you're seeing when you USE TABLE, BROWSE is like a parameterized view that returns enough records to fill the BROWSE window. Without parameters and without NODATA, using a view will pull all records.

To open a cursor and have the form appear instantly, USE dbc!newLocalView NODATA. This opens the view immediately, leaving an empty cursor with a structure you can use for showing a blank form.

You then ask the user for selection criteria and requery the view. Don't let them grab all data. *You* want them to have access to the entire data, but I'll bet if you ask them, they don't want it, nor can they really look at all of those records. No one *needs* to do that, especially with a million records. Go ahead and ask them what they look for most often. If they say they want to see all records, they've been tricked by the smoke and mirrors. Is your current approach to use some kind of index to show the data in reverse by date? That means they are already looking for the most recent data, not all data.

What I do is grab the records that match the criteria, but only show the most significant columns. The user scrolls to one record and switches to a detail view where I fetch all columns for that one record. If I have a query that returns 100 rows and the table has 50 columns, USE view, would grab 50 x 100 or 5,000 cells. If only 10 columns are significant, a better view would grab 10 x 100 or 1,000 cells. That's only 20% of the data in the first view. It can be 5 times faster to do that, and that's just for one user.

In my opinion, corruption can be significantly reduced by buffering (and views use buffering), but never completely eliminated. It can happen anytime data is being written to the DBF and power is cut, views or not.

>I've been using FoxPro for a number of years but am just now starting to work with local and remote views.
>
>I have a 1+ gig file that contains over a million records. I created a view of the table but when I USE dbc!newLocalView it now takes several minutes to load the view with data. During this time the user has to just wait until the query finishes running. Is there a way that that query can run in the background and release control back to the user immediately after the USE statement. There are many activities the user can do that are not related to the view that would be loading in the background, thus they could be more productive if they did not have to wait for the query to load before they can start using the application.
>
>I know that I can create paramerized views and limit the amount of requested data, thus it loads quickly but I want the user to have access to the entire database, once it is loaded.
>
>I've looked at several properties related to views but the ones that seem to relate to restricting the amount of data being 'fetched' only apply to remote views.
>
>In short, I'd like to use a local view but have it load instantly much like a normal DBF table. The reason I'm trying to convert from using a DBF table to view is to avoid data/table corruption issues. I've heard that if you are using views, you will rarely have a corrupted table. Is this correct?
>
>TIA,
>Robert