When we moved the DBC, we only had to VALIDATE the database to correct this. However, I have never been able to overcome the hard coding of the paths to a class library when mapping fields to classes in the DBC. Our solution has been to avoid this, standardizing the available VCX's for each developer's IDE...

I hope this makes sense...

Regards,

Jack

>OK, Jack, but what *do* you do about the hardcoded paths in the DBC????
>
>Bonnie
>
>>We have a different drive letter for our test server than our production server. However, we still use the DE in the forms, but set our paths in the main prg. We have found that this works for everything except the hard coded paths that end up in a DBC...
>>
>>Jack
>>
>>>>The property is disabled in the property sheet, but it is Writeable at runtime, onlye before the tables are open. So you have to call oyur code in the form.load or the DE.BeforeOpenTables method.
>>>
>>>OK, that makes sense.
>>>
>>>>IN response to your question in the other thread: The main advantage to using the DE is being able to visually manage what tables are available to your form's datasession. You can work without it, sure, many do. But you will have to write something that performs the tasks for you: locating and opening the tables.
>>>
>>>I've been programming for so very many years that writing code to perform these particular tasks is a no-brainer, it's something I've always had to do anyway. Hard to teach an old dog new tricks I guess.
>>>
>>>Thanks for your input,
>>> Bonnie