Ed,

>>>Is it possible to included an "index on name to name" in the grids recordsource property box??? I guess the "order by name" doesn't do it and I tried this which doesn't work of course "select name, yr_bred from master where type = "B" order by name into cursor addfoal noconsole inde on name to name".
>>>
>>>Sorry for being dense but I think I understand the concept, just can't find how to apply it.
>>>
>>>Can I create the cursor in the init of the form and then set the grids recordsource to it as a property???
>>
>> Your cursor has to be updatable in order to create index (index on command).
>
>That's absolutely incorrect. A cursor need never be updatable (updatable equates to being able to update the underlying table(s) it was formed from, like an updatable View), it must be writablein order to have a structural .CDX with >1 tag in it.
>
>You can create a single tag on a read-only cursor; the cursor needs to be made writable in order to have >1 tag created for it.
>
>You can create as many IDX indexes on a cursor as you want - the cursor need not be writable to have free-standing .IDX indexes. IOW, INDEX ON JRandomField TO IDX file rather than TAG TagName always works.
>
>Indexing a cursor created by a SQL Select to tags is potentially very dangerous if the result is a filtered view; if it is, the tags are added to the parent table's CDX, and might write over existing tags, or cause all sorts of interesting problems in a DBC if the table is a member of a DBC. And the truly sickening sinking feeling when it takes several minutes to create a new tag when the Select result is only 10 of 400,000 records in a table...but the filtered view is really dealing with the original table.
>
>> To make cursor updatable you can either create it in Init method of your form (or the grid) (Create Cursor command) or use dbf('myCursor') again alias myUpdatableCursor or wait till VFP 7.0, where we will have ReadWrite option :)
>
>Or the simpler method of SELECTing to a table in the first place, and < horrors > having to ERASE the file when you're done with it. Selecting to a file and cleaning up after yourself rather than using a cursor is not that difficult; it avoids the ever-popular 'gotchas' resulting from a SQL Select that creates a filtered view rather than a temporary file (avoidable IAC by adding 'NOFILTER' to the Select statement.)
>
>The code to clean up after yourself during closing of a temporary table is no more complex than the code needed to 're-use' a cursor to make it read-write

Thanks for the excellent explanation. I've known something important and new for me. I may revise my old applications to implement index on field to .idx instead of making cursors read-write. I will definitely consider it in a future.

Again, thanks a lot.