Doug,

I was aware of the 'use again trick' for local tables, but as I said my mistake was in thinking that cursors created with sqlexec from sql server were also read only. (BTW I had a conversation with Stephen Sawyer who advised me that there is now a READ-WRITE clause in 7.0, which is very helpful - but so far I'm still only using 6.0).

Thanks for the pointer on isreadonly() - I was not aware of that function.

Also, Stephen also pointed out that I can use cursorgetprop('SOURCETYPE') to determine the origin of the cursor. I am curious, however, as to how VFP knows the difference between these types of cursors. They all just appear to be regular temp tables when doing a disply status. Does VFP write something specific to the table header, or does it simply set the file attribute to read only? For example the help states:

SourceType N 1 – Specifies that the data source is a local SQL view.
2 – Specifies that the data source is a remote SQL view.
3 – Specifies that the data source is a table.
Read-Only.

How would you distinguish, for example, between a remote view cursor and a cursor created with sqlexec - both return 2. How would you distinguish between a cursor created with create cursor and a regular table - both return 3.


Thanks again for your help!

>Hi David.
>
>>Based upon my original incorrect assumption, I wrote very long 'create cursor' statements, and then programmaticaly loaded data into them.
>
>Another way to do this (for example, from a SELECT from local tables) is to USE DBF('cursor alias') AGAIN IN 0. The second copy of the cursor is now read-write.
>
>>I want to rewrite my code now that I know that I can update these types of cursors, but I want to make sure there are no caveats or circumstances under which I won't be able to update such a cursor.
>
>You could use ISREADONLY() to determine if the cursor is read-only.
>
>Doug