Bonjour.
Peut-être mais c'est pourtant le cas (au moins en VFP 6 et 7)
Et VFP5 et VFP3.0
En sachant cette information, on n'a qu'a programmer en consequence. 
C'est l'essence même de mon post ???? Pour programmer en conséquence, encore faut-il avoir cette information....
Je m'avoir mal expliqué. Normallement je met tourjours les tables dand le DE de mes formulaires, à mon avis il y a beaucoup d'avantage à faire ainsi qu'autrement Il y a de nombreuses methodes qui sont utilisé dans le DE qui s'occupe des tables, que tu évite completement en utilisant ta méthode.
Pour en remettre une couche : je trouve idiot en dangeureux d'utiliser le dataenvironnement vu qu'il conserve le chemin absolu de la table. Exemple vécu : tu mets 2 bases (et 2 applis) sur la même machine et tu te retrouves à avoir 2 applis qui pointent sur la même base (super de devoir retoucher 100 ou 150 forms pour corriger cela!
et imagine si tu en oublies un...). Avec des USE, no problem.
Apres 19 ans de programmation en FoxPro, le terme 'idiot' pour valider un mausaive technique de programmation n'est pas nouveau. Les chemins des tables n'est pas 'absolu' comme tu le dit si bien. Si par exemple tu crée un classe formulaire pour tout tes formualires et que tu ajoute use simple methode que remet les chemins 'a la bonne place', alors la tous tes formulaires vont réàgir de la meme façon avec une petite méthode que l'on écrit une fois. Il sans que dans ton exemple il faut forcer les chemins dans chaque formulaires (X 100). Et dans ton example si le client décide d'installé l'application sur le drive 'g', tu fait quoi? Voici une exemple d'un méthode qui remet 'les chemins à la bonne place' en se basant sur le chemin qui est indiqué dans un fichier INI.
* Use to fix the path for a table
* expC1 Name of the cursor we have to modify
* expC2 Alias (if passed will override the default cursor alias)
LPARAMETER tcCursor,tcAlias
LOCAL lcObject
lcObject="ThisForm.DataEnvironment."+tcCursor
WITH &lcObject
SELECT TABLE
* We will locate for record in TABLE.DBF
IF NOT EMPTY(tcAlias) AND TYPE('tcAlias')='C'
* We need to replace the Alias and the CursorSource properties
* because we will override the cursor
SEEK UPPER(ALLTRIM(tcAlias)) ORDER ALIAS
STORE tcAlias TO .Alias
STORE ALLTRIM(NOM) TO .CursorSource
ELSE
* If this is a view
IF UPPER(.CursorSource)='VIEW'
LOCAL lcDatabase
lcDatabase=SUBSTR(.Database,RAT('\',.Database)+1)
STORE oApp.cData+'\'+lcDatabase TO .Database
RETURN
ENDIF
LOCAL lcAlias,lnAt
lcAlias=SUBSTR(.CursorSource,RAT('\',.CursorSource)+1)
lnAt=AT('.',lcAlias)
IF lnAt>0
lcAlias=SUBSTR(lcAlias,1,AT('.',lcAlias)-1)
ENDIF
=SEEK(UPPER(lcAlias),'TABLE','ALIAS')
ENDIF
* We will replace the database property for those that are in a DBC
IF NOT EMPTY(DBC)
IF oApp.lMainIni
STORE oApp.cData+'\'+ALLTRIM(DBC)+'.dbc' TO .Database
ELSE
STORE ALLTRIM(DBC)+'.dbc' TO .Database
ENDIF
ELSE
* We will replace the CursorSource property with the full path
* for those not part of a DBC
STORE ALLTRIM(CHEMIN)+'\'+ALLTRIM(NOM)+'.dbf' TO .CursorSource
* If we are in a pick list or in a grid admin
* Because of a bug in Visual FoxPro 5, we are not allowed
* anymore to set the property of Database to blank
* This means we will use a technique to add a cursor here
* in order to have it blank at first
IF ThisForm.Name='recherche'
ThisForm.DataEnvironment.RemoveObject('Cursor1')
ThisForm.DataEnvironment.AddObject('Cursor2','Cursor')
ThisForm.DataEnvironment.Cursor2.CursorSource=ALLTRIM(CHEMIN)+'\'+ALLTRIM(NOM)+'.dbf'
ThisForm.DataEnvironment.Cursor2.Alias=ALLTRIM(NOM)
ThisForm.DataEnvironment.Cursor2.BufferModeOverride=2
ThisForm.DataEnvironment.InitialSelectedAlias=ALLTRIM(NOM)
ENDIF
* We need to remove the database
* .ResetToDefault('Database')
ENDIF
* If we are in adding mode, we have to change the buffering property to optimistic
* to have the possibility to create more than one record at a time for this form
IF TYPE('oApp.nRecnoToProcess')='N' AND oApp.nRecnoToProcess=-1
STORE 5 TO .BufferModeOverride
ENDIF
ENDWITH
Mike Gagnon