Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Problem with indexing on DELETED(). Bug or feature?
Message
From
16/09/1999 17:15:17
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00265288
Message ID:
00265668
Views:
22
Thanks, Jim - I've always wondered how this came to be.

Now I do question your last two sentences, though. I agree that read-only should be read-only - firm and final. But I feel that that should apply to the cursor, and I would not call an index (CDX or whatever) the cursor - it is a distinctly different file. Now the fact that VFP feels compelled to write to the table (cursor) header on a second INDEX creation could surely be overcome internally to VFP. In other words, It should be able "protect" that the table (cursor)itself will not be written-to by application code in any way while at the same time permitting any number of indexes to be created against that table. Alternately,VFP should be smart enough to recognize a read-only cursor and, if necessary for other (internal) reasons) keep track of indexes for such cursors through a separate mechanism that doesn't overwrite a table header.

Regards,

Jim N

>David,
>
>Ok, you asked so here's the answer.
>
>The cursor created by SQL SELECT in Fox has always been read-only (since FoxPro 2.x introduced the SELECT command). It is that way in order to comply with the ANSI '92 standard for SQL which states that a cursor created by a select command will accurately reflect the values of the data at the time that the select was executed or it will be capable of writing back to the original tables with any changes that have occured to the data.
>
>Since SELECT command does not produce an updateable cursor (views in VFP do this) then the cursor cannot be writeable.
>
>The issue of one tag only is actually a side effect of how VFP works. Technically you should not be able to produce any indexes on the cursor, but because VFP doesn't try to write to the dbf until the second tag is created, you can sneak in one tag. If yu want strictly work within the specs of VFP you shouldn't create any tags on a cursor created with SELECT.
>
>I can understand someone wanting to grouse after discovering what seems like errant behavior, but the fact is you were trying to do something that isn't supposed to be done. The real bug, IMHO, is that we can create any tag on a read-only cursor, not that we can create only one. Read-only should be read-only.
Previous
Reply
Map
View

Click here to load this message in the networking platform