VistaDB 5
Gibraltar VistaDB > Developer's Guide > How To Perform Common Tasks > How To - Create a New Database in Code
How To - Create a New Database in Code

Creating Databases

You can use the VistaDB Data Builder application to create databases in a graphical manner. But there are times when you need to create a database in code. Sometimes people include a blank database with their application and copy it to the customer machine at first run. I prefer to build the database dynamically for a couple reasons.

The first is just so you only have one place to make changes to the database schema. If you are always creating the database in code, you never have to worry about whether you copied the right database at startup.

Another is that you validate the users machine is completely setup and operating normal when you create the database. A user may not exercise your app at first startup, but creating the database and populating it with your default data is an excellent way to validate the installation succeeded and is working correctly.

I personally also find it easier when I need to upgrade users database on deployed machines because I already have all the code to generate a complete database, it is easier to build a small set of update functions to update the schema to an existing database.

See the How To Create a new database using SQL and How To Create a new database using DDA

Determining what version database schema your client is running

If you have more than one version of an application in the field you will quickly run into a versioning problem with which schema is on a target machine. Some programmers attempt to look at each table for "signs" that it has been upgraded. This is a bad practice. It makes it almost impossible to fully debug the scenario, and is very prone to errors.

I suggest you build a table for your database (I usually call my system). The purpose is to store specific information about your database that you may need at runtime. I normally store things like a schema version number, the date of the last backup, the date of the last pack operation, etc. Things that I could keep out in my application, but why? Especially if you have more than one app talking to the database, they may all need to know that the schema is the correct version before they run an important import or update.

See Also