- •Firebird 1.5 Quick Start Guide
- •Table of Contents
- •About this guide
- •What is in the kit?
- •Classic or Superserver?
- •Default disk locations
- •Installing Firebird
- •Installing the Firebird server
- •Installation drives
- •Installation script or program
- •Windows platforms
- •Posix platforms
- •Testing your installation
- •Pinging the server
- •Checking that the Firebird server is running
- •Windows NT4, 2000 and XP
- •Windows 9x or ME
- •Windows Control Panel applets
- •Posix servers
- •Other things you need
- •A network address for the server
- •Default user name and password
- •How to change the SYSDBA password
- •An Admin tool
- •Performing a client-only install
- •Windows
- •Linux and some other Posix clients
- •Working with databases
- •Connecting to the sample database
- •Server name and path
- •The CONNECT statement
- •Using isql
- •Using a GUI client
- •Creating a database using isql
- •Starting isql
- •The CREATE DATABASE statement
- •Firebird SQL
- •Division of an integer by an integer
- •Things to know about strings
- •String delimiter symbol
- •Apostrophes in strings
- •Concatenation of strings
- •Double-quoted identifiers
- •Expressions involving NULL
- •More about NULLs
- •Safety measures
- •Security options on the server
- •Backup
- •How to corrupt a database
- •Modifying metadata tables yourself
- •Disabling forced writes on Windows
- •Disabling Forced Writes on a Linux server
- •Restoring a backup to a running database
- •Allowing users to log in during a restore
- •How to get help
- •The Firebird Project
- •Alphabetical index
Firebird 1.5 Quick Start
It cannot be recommended too strongly that you use DDL – not direct SQL operations on the system tables – whenever you need to alter or remove metadata. Defer the “hot fix” stuff until your skills in SQL and your knowledge of the Firebird engine become very advanced. A wrecked database is neither pretty to behold nor cheap to repair.
Disabling forced writes on Windows
Firebird is installed with forced writes (synchronous writes) enabled by default. Changed and new data are written to disk immediately upon posting.
It is possible to configure a database to use asynchronous data writes – whereby modified or new data are held in the memory cache for periodic flushing to disk by the operating system's I/O subsystem. The common term for this configuration is forced writes off (or disabled). It is sometimes resorted to in order to improve performance during large batch operations.
The big warning here is: do not disable forced writes on a Windows server. It has been observed that the Windows server platforms do not flush the write cache until the Firebird service is shut down. Apart from power interruptions, there is just too much that can go wrong on a Windows server. If it should hang, the I/O system goes out of reach and your users' work will be lost in the process of rebooting.
Note
Windows 9x and ME do not support deferred data writes
Disabling Forced Writes on a Linux server
Linux servers are safer for running an operation with forced writes disabled temporarily. Still, do not leave it disabled once your large batch task is completed, unless you have a very robust fall-back power system.
Restoring a backup to a running database
One of the restore options in the gbak utility (gbak -r[eplace]) allows you to restore a gbak file over the top of an existing database. It is possible for this style of restore to proceed without warning while users are logged in to the database. Database corruption is almost certain to be the result.
Warning
Be aware that you will need to design your Admin tools and procedures to prevent any possibility for any user (including SYSDBA) to restore to your active database if any users are logged in.
Note
For gbak instructions see chapter 21, Database Backup and Restore, of Using Firebird.
For instructions about blocking access to users, see chapter 14, Getting exclusive access to a database, of Using Firebird.
If is practicable to do so, it is recommended to restore to spare disk space using the gbak -c [reate] option and test the restored database using isql or your preferred admin tool. If the restored
22