These steps are summarized as follows:
1. Provide a name for badge database
2. Create a data source, this includes selecting the database type and setting up the database parameters
3. Selecting the table name to contain the data
4. Defining the templates, photo compression method, database fields and optional field name aliases
5. Assigning the fields to the templates and naming the templates
6. Optionally, naming multiple photograph rectangles
Note: Some versions of the program do not use ODBC, so steps 2 and 3 are not relevant and neither is the following discussion on ODBC. These versions use the Borland Database Engine to directly create the Paradox tables.
Before we elaborate on these steps, some clarification of terminology is needed. The ODBC represents an attempt to standardize access across several different types of database managers. In this context, a table represents a collection of data (our badge database, for example) and a database is a collection of tables. As defined, the database might simply be a directory on the disk (Paradox, dBase and FoxPro use this approach) or it might be a file in which the tables are stored (MS Access, among others, uses this approach).
An ODBC Data Source is a definition of access to a database that can contain zero or more tables. Throughout this document we have referred to the place where the badge data is stored as the database. But in strict ODBC parlance, it is stored in a table in a database.
Reviewing the 6 steps above in light of this clarification, we see that step 2 creates the ODBC Data Source which defines the type of database manager to use (Paradox, Access, etc.) and where the database is located (which directory or file). Step 3 creates the actual table where the badge data will be stored.
Because a database can contain multiple tables, it would be perfectly acceptable to create one ODBC Data Source for all the badge databases that use a particular database manager and then create unique tables for each badge database. It would be equally acceptable to create separate ODBC Data Sources each using the same database manager and pointing to the same database.
To try to minimize the confusion this flexibility can cause, we will use the approach here that a new ODBC Data Source will be created for each table, even if several data sources might point to the same database.