>Since you are gathering selection criteria entered by the user, I am lead to think you are retrieveing records for the user to select from for editing purposes. If this is so, I highly recommend doing what I do. I also have an

Yeah, that's exactly what I would have thought going in, but unfortunately, in this particular instance, that's not really the case.

inquiry form for my users where I then create SQL on the fly to select records with. I then use SPT to retrieve a cursor, not a view stored in a DBC. I actually store this generated SQL in a global app, goAPP, property. The user is then sent to a form with a grid to display the cursor created by the generated SQL. In the form LOAD, I get the generated SQL string from the goApp property and use SQLEXEC() to retrieve the data. The SQL also contains the PK field. This type of query is very fast and can be optimized depending on what you allow for search criteria.
>
>They then select a record from the grid, the PK of the record is stored in a goApp property and an editing form is then run.

With minor differences, that is pretty much how my search screen class works.

In this case, however, the users did not want a search facility. They wanted a filter. They want an editing screen, not a browse, that, for example lets them navigate only a particular contractor's projects, or only projects where the description tells them, say, that the contract papers are in storage (or both criteria together). This is, in fact, the first project I've built that has NO search facility.

>
>Instead of using where descript $upper(somefield), you can partially optimize this by using where upper(somefield) like ?cValue as long as cValue = upper(alltrim(ThisForm.txtBox1.Value)) + '%' You can also use a % at the beginning or the underscore wild card where needed.

Good point. Very good, in fact. I'm going to change that part of the code straightaway.

Getting back to the original point though, as another experiment, I went back to my simple empty screen and redid it with the simple view pre-created. the view's select clause is simply:

Select * from ctracts

In this case, it is pre-created and lives in the database.

In the screen, I simply open it nodata and then do a requery(). Running the exe externally, the requery takes 9 seconds to load the data. This time, running the same exe from the VFP IDE, the requery() takes .4 seconds.

Do you have any idea what kind of things the external runtime might not like that the IDE does like? I mean that kind of time difference from the same exe makes no sense to me.

>Since you are using local data, just execute the SQL INTO CURSOR crsResults instead of using SQLExec. I use Oracle, and this technique really cooks. Plus, there are just some things your users just have to realize -- the more general their search criteria are, the less effecient the retrieval.

Yes, I know, but in this case, I'm the one who is the least satisfied with the situation. Beyond that I hate the idea of not being able to figure out what is causing the data to be requeried so slowly when run externally.

Thanks for all your time on this Mark.

Alan