Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Increment Field
Message
 
 
To
11/04/2008 17:21:16
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
Environment versions
Visual FoxPro:
VFP 9 SP2
Miscellaneous
Thread ID:
01309981
Message ID:
01310105
Views:
30
Hi Al,

You shouldn't use an alias in RECNO() or similar functions because a query always uses internal alliases for tables involved. If you do, than you reference an alias outside of a query.

>Here is some fun with RECNO():
>
>* Test1
>CLOSE DATABASES ALL
>
>CREATE CURSOR Test1 ( Char1 C( 10 ) )
>* We purposefully leave no rows in the first cursor
>
>CREATE CURSOR Test2 ( Char1 C( 10 ), OrderCol I )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "One", 1 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Two", 2 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Three", 3 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Four", 4 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Five", 5 )
>
>* Purposely set the currently selected table to
>* the first cursor instead of Test2 to see if we can fool RECNO():
>SELECT Test1
>
>SELECT ;
>  * ;
>  , RECNO( ) AS MyRecNo ;
>  FROM ;
>    ( SELECT ;
>      * ;
>      FROM Test2 ) DerivedTable ;
>  INTO CURSOR Output ;
>  ORDER BY OrderCol
>
>* Result: RECNO() was not fooled!
>Char1   OrderCol   MyRecNo
>-----   --------   -------
>One     1          1
>Two     2          2
>Three   3          3
>Four    4          4
>Five    5          5
>
>Since that worked fine, let's make darned sure RECNO() can't get confused by any other table open in the current work area. Same as above, except we'll explicitly specify the derived table alias, "DerivedTable", in the RECNO() function:
>
>* Test2
>CLOSE DATABASES ALL
>
>CREATE CURSOR Test1 ( Char1 C( 10 ) )
>* We purposefully leave no rows in the first cursor
>
>CREATE CURSOR Test2 ( Char1 C( 10 ), OrderCol I )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "One", 1 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Two", 2 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Three", 3 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Four", 4 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Five", 5 )
>
>* Purposely set the currently selected table to
>* the first cursor instead of Test2 to see if we can fool RECNO():
>SELECT Test1
>
>SELECT ;
>  * ;
>  , RECNO( "DerivedTable" ) AS MyRecNo ;
>  FROM ;
>    ( SELECT ;
>      * ;
>      FROM Test2 ) DerivedTable ;
>  INTO CURSOR Output ;
>  ORDER BY OrderCol
>
>* Result: Program error: "Alias is not found". But, we're explicitly referencing
>the alias of the derived table! Shouldn't this work? < g >
>
>Now, we get evil. We make sure there is a cursor named "DerivedTable" present before we run the SELECT:
>
>* Test3
>CLOSE DATABASES ALL
>
>CREATE CURSOR DerivedTable ( Char1 C( 10 ) )
>* We purposefully leave no rows in the first cursor
>
>CREATE CURSOR Test2 ( Char1 C( 10 ), OrderCol I )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "One", 1 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Two", 2 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Three", 3 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Four", 4 )
>INSERT INTO Test2 ( Char1, OrderCol ) VALUES ( "Five", 5 )
>
>* Purposely set the currently selected table to
>* the first cursor instead of Test2 to see if we can fool RECNO():
>SELECT DerivedTable
>
>SELECT ;
>  * ;
>  , RECNO( "DerivedTable" ) AS MyRecNo ;
>  FROM ;
>    ( SELECT ;
>      * ;
>      FROM Test2 ) DerivedTable ;
>  INTO CURSOR Output ;
>  ORDER BY OrderCol
>
>* Result: not what we hoped for:
>Char1   OrderCol   MyRecNo
>-----   --------   -------
>One     1          1
>Two     2          1
>Three   3          1
>Four    4          1
>Five    5          1
>
>Yes, these examples are contrived. But it shows that, behind the scenes, there is different behaviour at least between RECNO() (with no arguments) and the version where an alias is specified. There is probably some sort of function overloading happening, but it shows that there can be significantly different behaviour between the overloads.
--sb--
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform