Firebird 1.0.3 for Linux
========================

More information can be found about the Firebird
database engine from:

  http://www.firebirdsql.org

or affiliated sites:

  http://www.ibphoenix.com


The Firebird(tm) database engine is derived from the InterBase(r)
product currently owned by Borland.  The documentation for
InterBase v 6.0 applies also to the current FireBird release.
InterBase documentation is available in Adobe Acrobat format from
http://info.borland.com/techpubs/interbase/.


WHATS NEW IN FIREBIRD 1.0.3
===========================

There are two new features in this release:

o The artificial maximum index limit per table has been removed.
  This limit was set at 64 indexes and provided consistency across
  page sizes and regardless of the number of columns that made up the
  index. Under most circumstances even 64 indexes for a table is too
  many. Insert and update performance can deteriorate significantly when
  numerous indexes are defined.

  The purpose of this feature is to support data warehouse type
  applications where data is updated by a batch process, rather than
  interactively. When using this feature it is advisable to disable the
  indexes prior to a data load.

  The new limits for indexes are:

   Page Size     Single column        Double Column
   ------------------------------------------------
       1 k             60                    48
       2 k            124                    99
       4 k            252                   203
       8 k            508                   406
      16 k           1020                   816


o A control panel applet is now part of the Win32 installation
  package. It will install automatically by default but this option
  can be turned off at install time.


Bugs fixed in this release (all platforms)
==========================================

The bugs fixed are :

o The Service Manager api is now available to the command-line tools
  again. This was (un)fortunately the only bug known to be introduced
  by Firebird 1.0.2

o An event handler bug was fixed. Some Operating Systems that supported
  multi-threading were using out of band notification for events. This
  would lead to occasional, hard to diagnose problems.

o SIGPIPE errors on *nix Super Server builds were being logged excessively.
  This problem was benign, as long as enough disc space was available.

o Connection times had a built in delay of 1 second per attachment. This was
  fixed for Firebird 1.5 and the change back-ported to the Firebird 1.0.n
  code.

o A couple of buffer overruns have been fixed.


Bugs fixed in previous maintenance releases
========================================================

The main bugs fixed in Firebird 1.0.2 (all platforms) are:

o There was problem with connection strings on Unix platforms that
  could lead to database corruption.

o 64-bit file i/o is now properly supported under Linux

o Table name aliases are now allowed in INSERT statements. 

o String expression evaluation now throws an error if the expression 
  could be greater than 64k. Previously an error was thrown if the 
  expression evaluated to a possible size of greater than 32k.

o Minor problems with Two-Phase commit were fixed.

o INT64 datatype now supported correctly in Arrays.

o SF Bug #545725 - internal connections to database now reported 
  as user.

o SF Bug #538201 - crash with extract from null date.

o SF Bug #534208 - select failed when udf was returning blob.

o SF Bug #533915 - Deferred work trashed the contents of 
  RDB$RUNTIME.

o SF Bug #526204 - GPRE Cobol Variable problems fixed.


There was no official Firebird 1.0.1 release for any platform except
Mac OS X. That release was made to cater for an operating system upgrade.


WHAT WAS NEW IN FIREBIRD 1.0.0
==============================

For complete list of all new features, enhancements and bugfixes
refer to files stored in /opt/interbase/doc directory.


Enhancements:
- Enhanced dependency checking
- Large database file support
- Engine support for 64-bit file I/O
- Support for 16-kb pages
- Expressly define external file location(s)
- Win32 Forced Writes defaul=ON
- Limit raised on External Table handles (NT)
- External files now closed when external table is droped
- CPU_AFFINITY configuration parameter
- Connection now defaults to port 3050
- Connection to server listening on a specific port
- Added -NONAGLE switch for Linux ports
- Additions and changes to isc_info_database

Language enhancements:
- CURRENT_USER and CURRENT_ROLE
- DROP GENERATOR
- GROUP BY UDF
- RECREATE PROCEDURE and RECREATE TABLE
- SELECT [FIRST x][SKIP y]
- SUBSTRING built-in function
- New PLANONLY option for statements
- Allow FK indexes to be disabled
- Case insensitive Hungarian Collation set
- New comment marker for scripts

API Enhancements:
- Enhancements to isc_database_info



TROUBLESHOOTING
===============

A lot of what is explained below should be done automatically by the install 
process.  It is explanined here just in case it didn't do it correctly for
your circumstance.


1)  IS IT WORKING HOW DO I TELL?
 
    A quick smoke test to see if it is all working is as follows:

    
    $cd /opt/interbase/examples

    $/opt/interbase/bin/isql
    >connect employee.gdb;
    >select rdb$relation_name from rdb$relations;
    >exit;


    (In some cases you may need to provide a password to isql)

    $/opt/interbase/bin/isql
    >connect employee.gdb user sysdba password <password>;
    >select rdb$relation_name from rdb$relations;
    > show tables;
    >exit;

    Where password will be either masterkey, or in the 
    file /opt/interbase/SYSDBA.password.


    For a test using networking.

    $/opt/interbase/bin/isql
    >connect 'localhost:/opt/interbase/examples/employee.gdb'; 
    >select rdb$relation_name from rdb$relations;
    >exit;

    On a remote machine you can try the above replacing localhost with 
    the server name.  Remember you may need to specify the username/password
    in to get it to work.



2)  HOW DO I CHECK THAT THE SERVER IS RUNNING
 
    You can check if the server is running by.

    netstat -an | grep 3050 

    If something is listening on port 3050 then the server is running.
    If something is not running, then see next topics.


3)  TROUBLESHOOTING CLASSIC SERVER INSTALL

    The classic server works in two modes, it allows you to directly open
    the database files, in this mode it does not need a server.

    This is done if in classic you open databases with a diretory path only.

    $isql
    >connect '/opt/interbase/examples.gdb';

    
    If however you open files with the following 

    $isql
    >connect 'localhost:/opt/interbase/examples.gdb';

    Then the isql program connects to the local firebird inetd server program
    to service the request. 

    The configuration files for setting up the inetd (or xinetd) for the 
    classic server are as follows:

    The /etc/services file needs an entry as follows:
    gds_db          3050/tcp  # InterBase Database Remote Protocol"


    For inetd the /etc/inetd.conf file should have a line as follows 

    gds_db  stream  tcp     nowait.30000  root /opt/interbase/bin/gds_inet_server gds_inet_server

    You will need to restart the inetd process before the server will work.
    $ps -ef | grep inetd
    will give you the process id and

    $kill -HUP <pid>
    will instruct it to reread it's configuration file and listen on port 3050.


    Recent linux systems Redhat 7.0/Mandrake 7.2 and later have xinetd, The 
    process is fairly similar, except the firebord service is described via
    a file in /etc/xinetd.d/firebird.  There is a template version of this file
    in /opt/interbase/misc/firebird.xinetd, you should only need to copy the 
    file to that directory.

    After copying the file, to get the xinetd process to reread it's
    configuration files, first find the xinetd process id.
    $ ps -ef | grep xinetd

    Then send it a restart signal.

    $kill -USR2 <pid>
    And it will reread it's configuration file and listen on port 3050.   

    See the topic SERVER STILL WONT START for more info if requried.


4)  TROUBLESHOOTING SUPER SERVER INSTALL

    Super server runs as an inetd process.  There should be an ibguard process
    running and several (usually 3) ibserver threads running.

    The server should start with 
    $/etc/init.d/firebird start

    Installation problems for super usually revolve around the server not
    starting up correctly during installation.

    Often this is caused by either lack of permission to connect via tcp
    to the server process or a prior install (perhaps a classic server )
    already running.

    One bad side effect is that this could result in the initial SYSDBA 
    password not being set correctly.

    The password should be in the file /opt/interbase/SYSDBA.password, but 
    sometimes if the install couldn't
    talk to the server then the SYSDBA password may be the build default of 
    masterkey.

    The SYSDBA password in /etc/init.d/firebird is hardcoded, and has to be
    correct, so some use of the /opt/interbase/bin/changeDBAPassword.sh 
    script may be required to fix this sort of problem.

    If there are problems you may need to check the actual file for correct
    SYSDBA password and install location.

    If running the /etc/init.d/firebird start script does not work then see 
    the topic SERVER STILL WONT START for more debugging info.
    


5)  SERVER STILL WONT START

    If you are really having problems try running the server programs 
    directly, that way if there is any unsatisfied links they should show
    up. ie:

    $/opt/interbase/bin/ibserver   # for super

    and 

    $/opt/interbase/bin/gds_inet_server  # for classic

    and take note of any error messages.

    There may be a problem with an unsatisfied dynamic library link (ie it
    requires a library or version of a library that you do not have installed)
    You can check the dynamic library requirements as follows:

    $ldd /opt/interbase/bin/ibserver

    After this point try posting a question to a newsgroup on:
    http://firebird.sourceforge.net/newslists.php
    (The ib-support newsgroups is a good starting point).


6)  PROBLEMS CONNECTING TO SERVER

    Most network connect problems come down to the /etc/hosts.equiv file.
    It needs to have the host from which you want your clients to connect
    from in it.
    There can be problems if DNS is not configured where there are problems 
    finding the names of the hosts or where ip numbers are used.
    If this is the case placeing specific entries in the /etc/hosts file 
    is a good place to start.


    Try to connect to the server using telnet.

    $telnet server 3050 

    This will tell you if you can get to the server, failure could be becuase
    of no suitable entry in /etc/host.equiv or some firewall blockage, or the
    most common one, the server is not running.
 




