A few years ago I spent many hours with a problem which was caused by this bug, and I learnt my lesson.

When you drive your car over a nail in your own garage and have a puncture, you have three options:
1. Remove the nail
2. Mark the nail and try to avoid it the next time
3. Forget about the nail and hit it again and again (The Homer Simpson way)

I prefer number 1. :-)

>Tore, I use the same one since I read it here in the UT (may be from you)
>
>>Javier,
>>
>>pardon me for jumping in. Your code show why I NEVER use the file() function, because it is simply a dangerous function to use. Even if you specify a directory, it always checks in all the directories which is specified in set path to. So file('c:\test\yourfile.ext') will show true even if there is no c:\test\yourfile.exe on your HD, as long as you have a file called yourfile.ext in your VFP path.
>>
>>I always use the syntax

>>lFileExist=adir(adummy,myfile)>0

>>
>>>HI Doug,
>>>
>>>>>As far as I remember (I did not document this, nor did I report to you, it's my fault), the problem was that if I want to open a certain DBCX in a given lcPath, if there is another DBCX in the set('path'), the DBCX object instantiation takes the DBCX in the set('path') instead of the one that I want to open, even if I put the lcPath explicit in the init call.
>>>>
>>>>I haven't seen that, nor do I understand why it would happen. The only time VFP overrides the path you provide for a file is if you're running in an EXE, the file you specify exists inside the EXE, and you specify a file with the same name outside the EXE. In that case, regardless of the path you specify, VFP always uses the file inside the EXE. However, I'll check the code in DBCXMgr.Init and see if there's something there that may explain this.
>>>
>>>On example:
>>>
>>>

>>>		do case
>>>			case dbused(lcObject)
>>>			case file(lcDBC)
>>>				open database (lcDBC)
>>>			case file(fullpath(lcDBC, .cRegistryPath))
>>>				open database (fullpath(lcDBC, .cRegistryPath))
>>>			otherwise
>>>				open database (locfile(lcDBC, 'DBC'))
>>>		endcase
>>>

>>>
>>>The function file() returns .T. if the DBC is in the path, and this DBC gets open instead of the one It should. If one DBC is in the path (besides the one I'm trying to open), then the 3rd case never gets executed. Many users (developers) only deal with one set of Metadata, but if you deal with more you may find some of this situation.
>>>
>>>More suggestions (if I'm a pain just let me know):
>>>
>>>It would be nice to have more functions to manipulate tables, fields, ... For example: manager.addfield(), manager.removeField(), ...
>>>Right now it can be done, but one has to alter the table and then validate it (or manually add all items to the metadata) to incorporate changes in the fields. One has to take care of making this sync, and it would be helpful to have those functions.
>>>
>>>The data dictionary has a lot of the fields properties (length, decimals, type, ...), but some are missing, like the default value. I know this can be a function, but if I want to set it I have to go the the VFP functions and commands, and I would like to do data manipulation in only one place.
>>>
>>>Fields in the field repository cannot have custom field props, and I missed it a lot. Custom properties can define a lot of behaviour, and if I can't add this behaviour to the field repository I have to do double work (add the field as a certain type of field from the field repository and then set by hand all the custom properties), which can lead to mistakes too. And if I change the behaviour of a certain type of field, I have to go through all the tables and change the custom props.
>>>
>>>Regards,
>>>Javier.