Separating connection info from schemas

System

We are running OD6.0 on windows 2k3. We have three environments: dev, qa, and prod. Developers only have direct access to dev. Code/config files have to be moved to the others by app admins, who will not change any of the files included in the zip files we give them. Currently, all of our schemas are in our database.xml file along with our connection info. Each environment has a different host and password for the database. So, we have to make a copy of the database.xml file called database.xml.qa or database.xml.prod and have the app admin rename the file after delivery. I'm not overly fond of this, because it means the file that is used in prod has never actually been tested; it's pretty easy to foresee a situation where the developer makes a change to the database.xml in dev and forgets to update the .qa or .prod copy.

In the past (at other clients), using DD5.5 and 5.6, we have configured it so that database.xml contained only the connection info. We had a separate ddcfg for each datatype which would load the connection info from database.xml using a <data-deploy-elements> element with a filepath attribute that had the path to database.xml as the value. My colleague has been working to extract our schemas from database.xml into individual ddcfgs to follow that paradigm, allowing us to leave the database.xml untouched on the various environments once we have configured and tested them the first time. She ran into a bit of difficulty with this and opened a case with support. Support is telling her that what she wants to do is not a supported configuration.

I've gotten involved at the tail end, so I may be missing some nuance of the communication back and forth with support, but it seems to me that support is out in left-field on this one. Has anyone successfully done this sort of configuration with 6.0?

Migrateduser

Ah - I looked into this a little further and found out specifically what was going on. The ddcfg in question had two data-deploy-elements elements (one pulling in the schema and one pulling in the db info), which indeed is not a supported config. I've recommended moving the schema into the ddcfg to my colleague, which should straighten things out.