Thanks Brett

I have been working in the way you describe but many of my DBC containers are referenced by UNC paths.

This becomes dangerous since it is easy to open a DBC in a copy of the live data folder thinking you are looking at the tables you copied but instead you are still pointing at your live data tables.

There is also a problem referencing DBCs with the same name.

I have lots of utilities to help me deal with the problems all of this creates but it would have been far simpler if VFP had a flag tha always forced the DBC to look for tables in the same folder the DBC is contained in.

Maybe I should add this to the VFP 8.00 wish list.


>The way we work here is that all the data for development is the same as the live just stored in different paths. So when the developers develop they are using the l:\vf development path to do their work. When users use the live data they are using k:\vfapps. The databases and the tables and fields are all the same. So the developers are free to modify or add fields as they see fit in order to develop or maintain the applications. We also have programs that will load the developer site with data from the live site. Thus the developers can check their program changes against actual data.



>>I have been having a few problems in transferring data from one DBC to another if both DBCs have the same name. (See my earlier posting this thread)
>>
>>The problem is if they both have the same name then referencing them is difficult.
>>
>>I am wondering if maybe I should change over to naming my DBCs in a different way.
>>
>>For example
>>
>>MYDBC_Dev && for my developmet DBC
>>MYDBC_Test && for the test DBC the customers get to play with
>>MYDBC_Live && the live DBC
>>
>>This would also make me feel less nervous about accidents with the customers live data, since I often have to do a lot of extra checking to make sure its my test data I am messing with and not the customers live data.
>>
>>This would make copying out the development folder to the live area a bit more awkward but if you use UNC paths its awkward anyway becuase you have to check there are no refernces pointing at your development table.
>>
>>Does anyone have any good reasons for me not to do this?
>>
>>Or have I just stumbled onto something everyone has been doing for years anyway.
>
>The way we work here is that all the data for development is the same as the live just stored in different paths. So when the developers develop they are using the l:\vf development path to do their work. When users use the live data they are using k:\vfapps. The databases and the tables and fields are all the same. So the developers are free to modify or add fields as they see fit in order to develop or maintain the applications. We also have programs that will load the developer site with data from the live site. Thus the developers can check their program changes against actual data.