>>>>Hi Gary,
>>>>
>>>>the oplocks comments are sound. As we found out when we deployed our app back in 2002.
>>>>
>>>>BUT -- when a file is over a certain size (seems like it was about 200MB), we found a slowness in opening that no amount of changing indexes, etc. fixed. And these openings were being done with NODATA. I looked at it with Filemon, advanced options, and what I saw was every record being scanned.
>>>
>>>I've found that using CREATE CURSOR is much faster than NODATA with complex SQL and even faster than asking a remote database for an empty structure.
>>
>>Of course, as it doesn't visit the server at all.
>>
>>Getting an empty cursor from another side accomplishes two things Create Cursor doesn't: gets you the latest structure, and checks that you can get it. Since this empty is usually retrieved early on, before the user did anything, it is the right time to do such a check. Having the user wait a bit is far better than hitting him with an error message when trying to save.
>
>If the user attempts to add a record, I switch from the CREATE CURSOR cursor to a real cursor from the back end. If the user edits a record, of course, I grab the record from the back end. The create cursor is only done to let the forms load really fast. The switch to a real cursor happens only once, when the user first causes it.

Ah, so you're starting with a blank form. Not the case in most of the stuff I was working on recently. Yes, it mostly starts with an empty search form - but even that has a couple of MRU lists, and then it loads the big form with dozens of cursors related to the found item. And these need to be populated immediately, without any further action of the user. So... yes, if I remember what you were showing me years ago, in your case Create Cursor makes much sense; in my cases it wouldn't gain me much.