Before creating a database

Should the database be SQL Server or Microsoft™ Access?

Microsoft Access databases offer most of the features of iBase and creating each database is simpler. However, over time and with growing size or numbers of databases, you might find that administration becomes difficult.

For personal use, and especially for use with a portable computer, an iBase Access database might be the best choice. You can always upsize any iBase Access database to SQL Server, allowing a straightforward transfer of all data and folder objects to the new format.

In general, the advantages of SQL Server databases make it the preferred choice:

• The advantages include the ability to work with larger databases, more users, better performance with large databases, and a higher level of data security with more flexible access control.

• You need to use one or more of the features specific to SQL Server databases. For a summary of these features, see Comparison of Access and SQL Server Databases.

The different combinations of Microsoft Access and SQL Server databases and security files are summarized in Configuration Options for an iBase System.

System requirements

All iBase installations can use Access databases. Multi-user sites need only a shared disk folder on a suitable server.

If you decide to use SQL Server, you need the following before you create an iBase database:

• SQL Server instance on a server or locally

• Suitable logins on that server

For more information about SQL Server logins, see Access control.

Identifying other database requirements

There are also some standard decisions to make for each database.

• Should the database have Federal Information Processing Standards (FIPS) compliance enabled?

  If you are working in environments that enforce FIPS compliance, you must enable FIPS when you create your database. FIPS enablement cannot be modified later because this changes the encryption algorithms, and existing users are prevented from logging in.

Before you create database records, you should consider the following questions:

• Do you want to identify records in this database uniquely when combined with records from other iBase databases?

  If so, you need to choose a text string, up to 5 characters long, that is unique to this database and that can be guaranteed to remain unique as new databases are created. (This is mandatory for replicated iBase databases.)

• Should the data be read-only to users?

  For example, this state might be appropriate if the database is used only for analysis of historical data collected from other databases. Database administrators can change this setting at any time, but you might prefer to make such a database read-only from the time of creation and change it to an editable state only when necessary for a specific task. Only the data is read-only, users (depending on their permissions) can still add, modify, and delete folder objects, such as queries.

• Should the database be partitioned by case?

  Do you want to restrict access to the records in the database on a case-by-case basis? If so, you need to create a case-controlled database. However, this setting cannot be changed at a later date. For details of how case control works, see What is case control?

With the exception of case control and FIPS, most other decisions can be made now or easily modified after the database has been in use for some time. For example:

• What level of auditing is appropriate?

  A low or intermediate level of detail is often a good starting point, because it is easy to modify settings for operational databases.

• Should audit logs contain a cross-reference for records from external data sources?

  If you do not have this need, there is nothing to do now. If you want this functionality, the process is complex and extends across database design, configuration choices, and auditing.

With the answers and information that is prompted by these questions, you are ready to create the database.

Logging on to the correct security file

You must be logged on to the correct security file when you create the database. The new database can only be accessed through this security file. In iBase Designer, the name of the security file is displayed in the second area from the left of the Status Bar at the bottom of the application window.

Note: Each database shares a unique identifier with the security file used when you create the database. You can only use the database with this security file (or with a copy of the security file).