We're a long time SQL Anywhere+Delphi development shop. A lot of our developers have come up with their own simple implementations of how to manage the version of a SQL Anywhere database schema with its related delphi application(s). However we're wanting to standardise how we do this, so thought we'd use this fantasic resource. By manage, I mean:
So, what do other SQL Anywhere developers use to version control their schema? |
We use PowerDesigner to manage the schema. The CDM and PDM Files are in a classical CVS Repository. Each Procedures, Function and View is stored a SQL Script. Changes to the Database are always done by a update script. This scipt uses the All sql scripts are hold in a CVS Repository. When we release a new version of the client Application we tag the Scripts and the PD Files in the CVS with the client version they are intended for. Update_x_zzz.sql
The function We write the DDL manually based on the PDM but you can also use the DDL Script Power Designer can generate and embed them by Thanks for the answer TDuemesnil. How do you get the changes into the sql script? Does each developer do it manually? And what if there are versioning issues with a PowerDesigner schema when it comes time to commit it to your CVS repo? Each Developer works on his own update main script. When he has finished his work he has to checkout all changes done by others. We use http://winmerge.org/ and http://www.tortoisecvs.org to check for conflicts in changes. Then he can finalize his update script and check in all changes. PowerDesigner has its own Compare and Merge Model possibilities. You have to have the old and new version available to use them. As you use subversion you know http://tortoisesvn.net ? Sure and we use that. You indicated you have multiple update scripts which are applied to the db. How do you know in which order to run the script as there could be dependencies among the different scripts? |
Since we develop 'package' software to be deployed to multiple sites, we implement schema changes via a script file to insure it is easily repeatable; the last line in that script updates a schema version setting (a particular row in a "settings" table). We maintain an "expected schema version number" in our app and check that against the "schema version" in the db at app startup. |
We use PowerDesigner first off. Unfortunately, we don't have the Repository feature, so we handle the 'versioning' with good'ole Copy+Paste of the PDM file. We then have our application version stored in the database, and then when the application connects, it compares. It has its faults, but it works out pretty well in the end. |