Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Indexing on DELETED() - VFP6.0
Message
From
09/10/2002 22:40:57
 
 
To
09/10/2002 22:01:55
Gavin Reid
L & M Marketing Pty Ltd
Frenchs Forest, Australia
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00709654
Message ID:
00709660
Views:
21
This message has been marked as a message which has helped to the initial question of the thread.
I ran your code in both VFP6 SP5 and VFP7 SP1 and I got the table name in ALL instances.
I believe that this is because VFP, for a simple SQL select (one involving only 1 table) produces a "filtered result set". That is, it actually uses the real table and applies a filter to present the results expected.

To test this I revised the VFP6 SP5 code to include a NOFILTER clause in both of the SQL select statement.
This time BOTH MessageBoxes showed the cursor name, so I think it proves the point.

I can only guess that the reason you get results different than mine is related to a different SP level or possibly some environmental thing. I ran on XP-home, on a machine with 512meg

good luck



>Hi All,
>
> I've noticed something weird with a Visual Promatrix 6.0b project I'm working on. Promatrix by default gives each table that you create an Index on DELETED(). This is done because Promatrix has the option to recycle deleted records, so having an index on DELETED() will allow deleted records to be located quickly.
>
>INDEX ON DELETED() TAG deleted
>
>In a number of places within the App I have code to turn a cursor created by SQL into a writeable cursor. E.g:
>
>SELECT myfield1,myfield2 ;
>   FROM mytable ;
>   WHERE mywherecondition ;
>   INTO CURSOR mycursor
>USE (DBF("mycursor")) AGAIN IN 0 ALIAS mywriteablecursor
>USE IN mycursor
>
>I've noticed that when looking at the DBF() of the cursor when the source table has an index on DELETED() it returns the DBF of the source table, but when dropping the DELETED() index and recreating the cursor the DBF() of the cursor returns the temporary cursor name as expected. The following code proves my point:
>
>CLOSE DATA ALL
>
>SET DEFAULT TO [c:\myfolder]
>
>CREATE DATABASE testdbc
>
>CREATE TABLE testdbf ( testfield C(1) )
>INDEX ON DELETED() TAG DELETED
>
>INSERT INTO testdbf ;
>    VALUES ( "1" )
>
>SELECT * ;
>    FROM testdbf ;
>    INTO CURSOR testcursor
>
>* ----- CURSOR DBF appears to be the same as the TABLE DBF
>*       BAD
>MESSAGEBOX("TABLE DBF is " + DBF("testdbf") ;
>	 + CHR(13) ;
>	 + "CURSOR DBF is " + DBF("testcursor") ;
>	 , 64 ;
>	 , "TABLE Indexed on DELETED().")
>
>USE IN testcursor
>
>SELECT testdbf
>DELETE TAG deleted
>
>SELECT * ;
>    FROM testdbf ;
>    INTO CURSOR testcursor
>
>* ----- CURSOR DBF appears to be a temporary file name
>*       GOOD
>MESSAGEBOX("TABLE DBF is " + DBF("testdbf") ;
>	 + CHR(13) ;
>	 + "CURSOR DBF is " + DBF("testcursor") ;
>	 , 64 ;
>	 , "TABLE not Indexed on DELETED().")
>
>
>Can anyone explain why this is happening? I've worked around the problem by removing the DELETED() Index Tags from my tables as I don't use record recycling, but I'm curious as to why this behaviour is occuring. Why would adding an index on DELETED() cause this? I've even changed the name of the Index Tag to something other than 'deleted' and the problem still occurs.
>
>Thanks,
>Gavin...
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform