Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Increment Field
Message
 
 
À
11/04/2008 17:21:16
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP2
Divers
Thread ID:
01309981
Message ID:
01310105
Vues:
31
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--
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform