>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.