Hello Kevin

In our department we have to keep our data on one server and our applications on a seperate server.
Then as long as we do all our code through views we can be pretty sure we can upsize easily if neccesary.

Keeping the data seperate in this way also means that the network guys can back up your data without having to back up all the executables.

It was also a requirement expected of us for any apps being developed using Citrix winframe. They wanted just the EXE and an INI file running on the terminal server box.


The main hiccups I came across where the usual bag.

1. When copying the data folder between its Development/Test/Live locations we had to run a wizard we got from the files section in here to sort out the links between the DBC and the tables. This Wizard did not understand UNC \\servername\ style paths so we altered it so it would.

2. Shipping out structure changes whilst retaining the existing data can be a pain which is why many folks in here ensure all this is done using code that regenerates the database container and its tables. This has other adavantages as well. I have tried to add some code to the wizard above so it will impact my latest set of structures and then re-import the data from a backup of the data it made before it started. The routine is only half finished so it is too flakey to wish on anyone else:).

3. The forms data environment stores a path to the tables it . If this is a UNC path then it will merrily open the wrong table for you if it gets the chance (whilst it is setting delete off at the same time) MAJOR PITA! I no longer let the form open tables for me I use my own data enviroment class.


Once you get used to it all everything works just fine. I pulled a few hairs out on route though:)


>Has anyone created an app with 2 identical DB's, 1 live and 1 test, and if so, were there any hic-ups when using then side by side.
>
>Thanks
>Kev