>Hi Terry,
>I'm jumping in without checking all the issues...
>I want an error, that's the point. I don't want the user to get a dialog that's pointless, and then my errorhandler's dialog saying "Sorry, you didn't open the right file." It's an error and we're all very sorry. Just give it to me. We want an error to throw an error--not a dialog, then an error.

I don't use SQL SELECTS with DBF (thats what SEEK is for:).

But if a select attempts to open a file thats not vailable - then it is an error. If ON ERROR don't catch it - then the next best thing is OPEN DIALOG. When we test our apps and the OPEN DIALOG pops up - we should fix the error or simplify the paradigm.

I have a hard time understanding why many of us are SELECTING from DBFs. Typically, when we do that, we bloat the CDX (I've seen an index on every field). SEEK is lower level- seek is faster - seek does need a result cursor - and when planning an app using seek, the discipline seems to force more normalicy and optimization - plus - we don't have to index on every field!

I habor a fear: That prospects may have negative feelings about VFP because of an over use of SELECT, TABLUPDATE, Modal FOrms and binded controls - they seem to slow every thing down - turn VFP in a list server rather than a powereful inteface tool.

Just my 2 cents: SEEKS SCANS REPLACE and hard bound assignments offer a lot more performance than those MACRO commands. And the app is less sloppy - turns a 100K lines of code app into a manageble 20Kline of code app.