Open Bugs

Category: Build Issues

SF ID Description Group/Status  
479041 Binary files not marked as such in CVS Confirmed Bug
 
I've noticed that some files in client-java are not marked as binary in CVS, resulting in corrupt files being checked out on Windows. All *.jar files in client-java/lib and client-java/src/lib are affected.

420205 FirebirdCS 9-4 p1 hostname sensitivity Initial Bug
 
The server process exit on signal 11 depending on the host name causing client software to stop functionning correctly :
- IBaccess 0.98 with database properties on filename tab for exemple report | instead of the real filename /home/data/file.gdb for example
- IB_wisSQL doesn't work correctly.

I have find this problem with hostname such as : easduerne.xxxfrance.com. Seems to work better with shorter hostname such : easxx.xxxfrance.com. Seem's like string overflow depending on the hostname.

Category:

Client/GDS32
SF ID Description Group/Status  
428605 Cannot dlopen libgds under Linux Initial Bug
 
When php interbase extension used as module, it links libgds dynamicaly with dlopen and unloads libgds with dlclose (dlfcn.h). Because libgds registers in init() gds__cleanup with atexit(), when program exits, it calls gds_cleanup, but gds_cleanup is not in program (libgds was freeed by dlclose()). Under Linux problem may be fixed by using _init and _fini functions exported by libgds. Example is appended. Function _init is called, when shared library is loaded (by dlopen or when library is linked with compiler when linking) and function _fini is called when shared library is unloaded (as _init). By exporting and using this functions, libgds needs not use atexit to register gds__cleanup.

This interface works in Linux and Solaris, under Windows may be used dllmain function for similarily functionality.
     DllMain (HANDLE hInst,
     ULONG ul_reason_for_call,
     LPVOID lpReserved);
ul_reason_for_call may be:
      DLL_PROCESS_ATTACH:
      DLL_THREAD_ATTACH:
      DLL_THREAD_DETACH:
      DLL_PROCESS_DETACH:
but I don't know what is shared by all process when linking the same library.

Category: Core Engine

SF ID Description Group/Status  
426607 'Starting with' and empty parameter Initial Bug
 
When Starting with ?param is used and param='' and optimizer uses an index, no one record appeares in result data set.

479483 Bad treatment of FIRST/SKIP in subselect Confirmed Bug
 
Commands like:
     delete from table where col in (select col first 5 from table);
doesn't delete up to five rows, but whole table. Obviously subselect is executed for each row in master table, but it should not when FIRST is in game.

221960 Classic Wrong Page Type Error Initial Bug
 
In testing classic 6.01 on Linux (pressing it pretty hard), I get:

database file appears corrupt ()
-wrong page type
-page xxxx is of wrong type (expected 7, found 5)

I cannot give you any details to really help reproduce the bug, apart from the fact that there were 5 clients attached and hammering the server, and a backup taking place about half the time.

I have, however, managed to get the error twice in a 48 hour period. Both times I was unable to get the database into a state where I could successfully back it up using gfix, and had to start the testing again with a fresh (empty) database.

Looking at the log file, I have an INET/inet_error: read errno=104. I'm not sure if this is the cause or result.

I also have another page xxx is of wrong type (expected 7, found 5) error reported in the log file for a different page, with the following additional information:
internal gds software consistency check (record disappeared (186))

461712 Computed field crashes server Initial Bug
 
If I have a stored procedure which computes a debtor's account balance at a specified date eg:
     create procedure debtor_balance_at(
       account_id integer,
       balance_date date )
     returns (
       balance_total numeric(18,2),
       balance_outstanding numeric(18,2))
     as
     begin
       /* the real procedure is more complex, but this works as an example */
       select balance_total, balance_outstanding
       from debtor_balance
       where (account_id = :account_id) and (balance_date = :balance_date)
       into :balance_total, :balance_outstanding;

       suspend;
     end
and I create a computed field on the debtor_account table:
     alter table debtor_account add balance_outstanding
     computed by (( select balance_outstanding
        from
        debtor_balance_at(
     debtor_account.account_id, 'today' )));
The next time I connect to the DB and access the computed field, the server crashes!

There's a fix/workaround. Change the computed field to use current_date instead of 'today'.

431381 Connection Lost when creating a trigger Initial Bug
 
When I try to create a Before insert trigger on a view I get a connection lost. After I made some test I found the problem. It has something to do with the fact that I use 2 times the same table column name in the view.

The syntax for the trigger is :
     CREATE TRIGGER BI_VW_RESERVATIONS FOR VW_RESERVATIONS ACTIVE
     BEFORE INSERT POSITION 0
     AS
     BEGIN
       NEW.ZIP_CODE = ''; /* Not Null field */
       IF (NEW.LOCATION_ID IS NULL) THEN
       BEGIN
         IF (NEW.RESERVATION_LOCATION_CODE IS NULL) THEN
         BEGIN
           SELECT SUPPORT$LOCATIONS.LOCATION_ID
             FROM SUPPORT$LOCATIONS
            WHERE (SUPPORT$LOCATIONS.CODE = NEW.RESERVATION_LOCATION_CODE )
             INTO NEW.LOCATION_ID;
         END ELSE
         BEGIN
           NEW.LOCATION_ID = 5;
         END
       END
       INSERT INTO RENTING$RESERVATIONS (RESERVATION_ID, MEMBER_ID, OBJECT_ID, LOCATION_ID)
            VALUES (NEW.RESERVATION_ID, NEW.MEMBER_ID, NEW.OBJECT_ID, NEW.LOCATION_ID);
     END

449312 Create External Table with relative path segfault Initial Bug
 
The following:
       create table foo external file 'foo.dat' (bar char(10));
Results in: Segmentation fault

An external file without an absolute path doesn't make sense, but we should not segfault.

224810 DISTINCT propagates outside a VIEW Confirmed Bug
 
Given these two views:
     CREATE VIEW VDISTIDX (RDB$RELATION_NAME) AS
      select distinct rdb$relation_name from rdb$indices
      
     CREATE VIEW VDISTIDX2 (RDB$RELATION_NAME) AS
      select rdb$relation_name from rdb$indices
     group by rdb$relation_name
Then
     select count(*) from vdistidx v
     join rdb$relation_fields rf on v.rdb$relation_name = rf.rdb$relation_name
with the optimizer reporting PLAN SORT (JOIN (V RDB$INDICES NATURAL,RF INDEX (RDB$INDEX_4))) produces a different result than
     select count(*) from vdistidx2 v
     join rdb$relation_fields rf on v.rdb$relation_name = rf.rdb$relation_name
with the optimizer reporting PLAN MERGE (SORT (RF NATURAL),SORT (SORT (V RDB$INDICES NATURAL)))

Notice both JOIN statements produce different query plans but both views alone produce the same plan. I think that the first case is a bug: the DISTINCT clause is propagating outside the VIEW; just change the fist case to become
     select rdb$relation_name
     from VDISTIDX v
     join rdb$relation_fields rf on v.rdb$relation_name = rf.rdb$relation_name
and you'll observe that effectively, the DISTINCT applied to the result of the JOIN, leaving each table name only once.

428903 Exception Handling Bug Initial Bug
 
If you raise user defined exception (by EXCEPTION command) and it is handled by WHEN ANY DO or WHEN EXCEPTION ... DO then changes made by that SP are NOT undone !!

Here is an example:
     CREATE TABLE tab (i INTEGER);
     CREATE EXCEPTION e 'abcd';
      
     /* Division by zero in this SP will cause INSERT to be undone */
      
     CREATE PROCEDURE proc1
     AS
     DECLARE VARIABLE x INTEGER;
     BEGIN
       INSERT INTO tab VALUES (123);
       x=1/0;
       WHEN ANY DO EXIT;
     END
      
     /* Calling EXCEPTION and handling it by WHEN ANY in this procedure does NOT undo INSERTed row !! */
      
     CREATE PROCEDURE proc2
     AS
     BEGIN
       INSERT INTO tab VALUES (456);
       EXCEPTION e;
       WHEN ANY DO EXIT;
     END
      
     /* Here is called EXCEPTION, but it is not handled by WHEN ANY, so inserted row will be correctly removed. */
      
     CREATE PROCEDURE proc3
     AS
     BEGIN
       INSERT INTO tab VALUES (789);
       EXCEPTION e;
     END
      
     EXECUTE PROCEDURE proc1;
     EXECUTE PROCEDURE proc2;
     EXECUTE PROCEDURE proc3;
      
     SELECT * FROM tab;
     I
     =======
     456
Error!!! Table should be empty.

435238 Firebird 0.9.5.156 memory leaks Initial Bug
 
this build has some problem with memory (server occupies too much memory and then hangs) on heavily loaded Database.

228030 Float problems. Initial Bug
 
I found some problems with float type decimal part. For example, write to field: FLOAT 0.35 physicaly it writes 0.349999994039536.

442140 Grant for Roles on Views not working Confirmed Bug
 
The system is reporting that I don't have select rights on a table, when I select from a view which has select rights on the table.

1. Restore the DB
2. Create a new user
3. Make the user member off CALS_USER
4. Login with that user and the role CALS_USER
5. Execute the following statement.
     SELECT * FROM VW_OBJECTS.
Generates the error: "No Select/Read rights on table catalog$lookup_info."

222376 Horrible plan with a lot of OR conditions Confirmed Bug
 
     select distinct doc.id docID, doc.directory directoryID
     from documents doc, DOC_APPLICATION docAppl
     where (docAppl.DOC_ID=doc.ID) and
     (docAppl.SITE_ID=2 or docAppl.SITE_ID=7 or docAppl.SITE_ID=25 or ....)
the corresponding plan is:
PLAN SORT (JOIN (DOC NATURAL,DOCAPPL INDEX (RDB$FOREIGN122,RDB$FOREIGN123,RDB$FOREIGN123,RDB$FOREIGN123,RDB$FOREIGN123...)))

And an RDB$FOREIGN123 is added for each additionnal or docAppl.SITE_ID= in the query. In one particular circumstance the query gets particularly long and the corresponding plan as well... In that case I'm getting the unknown error in ISQL (the records are fetched and presented in the dbgrid, statistics are here, but plan is empty).

And yes, IB does a very poor job at generating the plan in this particular case, the optimal plan is just:
PLAN SORT (JOIN (DOC NATURAL,DOCAPPL INDEX (RDB$FOREIGN122,RDB$FOREIGN123))

223514 IB crashes with two procedures intermixed. Confirmed Bug
 
These two procedures expect an order and an order-line number. The following will make IB crash:

Show all possible parties on stock, with the same characteristics
     select * from GET_ORDVRD(258,1)
Show the status of the stock (matched, alternatives etc)
     select * from INKORDVRDSTATUS(258,1)
First one
     select * from GET_ORDVRD(258,1)

217042 IB doesn't validate weird constructions Confirmed Bug
 
1)
     create table t0(check(0=0))
How can a table constraint be made without any field? I thought at least one field should be defined.

2)
     create table tgen2(a computed by(0))
     create table tgen3(a computed by(0/(0)))
     create table tgen4(a computed by(rdb$db_key))
Do you see any value in accepting this declaration? A computed field alone? I can never have a row.

3)
     create table tgen5(a int, b computed by(rdb$db_key))
Insert values in field a and then try to select = string truncation or arithmetic overflow.

4)
     create domain dint int default 'hello' not null
This is only a small example. IB never validates the default for any type of field. I can insert any kind of crap as default for domains of any datatype and also for fields defined inside a table.

419065 Join on diffrent datatypes Confirmed Bug
 
I have the same field, in one table as char(10) (named FZDNR) and in the second table as NUMERIC (HNR). I need the following select expression:
     SELECT * FROM WA WHERE HNR NOT IN (SELECT FZDNR FROM H)
In the pre-6 Versions of Interbase it was working fine, but now I get the whole table WA, so I think the join on HNR-FZDNR doesnt work. Tell me pls, is it a bug or is it an feature?

422240 Left join with stored procedure Initial Bug
 
We have two stored procedures and want to do:
     select * from proc1('AAA') p1
     left join proc2('AAA') p2 on (p1.id=p2.id)
if execute this query - server crashes.

221925 Left joining table to SP: ORDER BY makes fields NULL Confirmed Bug
 
     CREATE DOMAIN JOBCODETYPE AS VARCHAR(20);
     CREATE DOMAIN STOCKCODETYPE AS VARCHAR(30);
      
     create table Submit (
       jobid jobcodetype		not null primary key,
       completeby timestamp
     );
      
     create table Faults (
       id stockcodetype		not null,
       whenreported timestamp		default 'Now' not null,
       whendone timestamp,
       jmsref jobcodetype		not null,
      
       primary key (id,whenreported),
       foreign key (jmsref) references Submit(jobid) on update cascade
     );
      
     create view xAllFaults(jobid) as
       select distinct jmsref from Faults;
      
     create view xWaitingFaults(jobid) as
       select distinct jmsref from Faults where whendone is null;
      
     create view AllFaults(jobid,waiting) as
       select XAllFaults.jobid,XWaitingFaults.jobid from XAllFaults left join XWaitingFaults on XAllFaults.jobid = XWaitingFaults.jobid;
All jobid's with faults, and 'f' or 'F' according to if any are undone
     set term !! ;
     create procedure JobFaults returns
       (jobid varchar(20), fault varchar(1))
     as
     declare variable waiting varchar(20);
     begin
       for select
         XAllFaults.jobid,XWaitingFaults.jobid
         from XAllFaults
           left join XWaitingFaults on XWaitingFaults.jobid = XAllFaults.jobid
           into :jobid,:waiting
       do
       begin
         if (waiting is null) then
           fault = 'f';
         else
           fault = 'F';
      
         suspend;
       end
     end!!
     set term ; !!
      
     insert into Submit values ('A',cast('Now' as timestamp));
     insert into Submit values ('B',cast('Now' as timestamp));
      
     insert into Faults(id,whenreported,jmsref) values ('item A',cast('Now' as timestamp),'A');
     insert into Faults(id,whenreported,whendone,jmsref) values ('item B',cast('Now' as timestamp),cast('Now' as timestamp),'A');
Now try the following:
     select * from Submit
       join JobFaults on Submit.jobid = JobFaults.jobid
       order by Submit.completeby;
Here there appear to be no faults joined to the Submit table
     select * from Submit
       join JobFaults on Submit.jobid = JobFaults.jobid
Yet here the fault is shown correctly joined!!

This report is very similar/identical to SFID 228716.

223058 Multi-hop server ability broken Confirmed Bug
 
The feature that allows you to connect to IB server through several other IB servers, like:
alpha:beta:\\gamma\delta:C:\InterBase\db.gdb
does not work, if one of the relay servers (i.e. alpha, beta, gamma from above example) is IB6.

IB6 will allow connection, but when trying to execute any command you will get
Dynamic SQL Error
-SQL error code = -901
-feature is not supported

228135 NULL is returned as zero through a left join in simple VIEW Confirmed Bug
 
Consider:
     select pvb.project, pvb.mjr, pvb.mnr, pvb.rls, pvb.bld, b.id, b.priority, b.entered_by, b.closed, b.status
     from bug b
     left outer join project_version_bug pvb on (pvb.bug = b.id)
     where b.assigned_to = user;
      
          PROJECT     MJR     MNR     RLS     BLD           ID PRIORITY ENTERED_BY                      CLOSED STATUS
     ============ ======= ======= ======= ======= ============ ======== =============================== ====== ======
      
                1       0       0       0       0            1        1 SYSDBA           N      A
                1       0       1       0       0            1        1 SYSDBA           N      A
             null    null    null    null   null           2        1 SYSDBA          N      A
This is correct, you can see the null values where there are no records in project_version_bug for bug id 2. However, using the BUG_ASSIGNED view (which is defined with exactly the same SQL statement) I get the following:
     select * from bug_assigned;
      
          PROJECT     MJR     MNR     RLS     BLD           ID PRIORITY ENTERED_BY                      CLOSED STATUS
     ============ ======= ======= ======= ======= ============ ======== =============================== ====== ======
      
                1       0       0       0       0            1        1 SYSDBA           N      A
                1       0       1       0       0            1        1 SYSDBA           N      A
                0       0       0       0       0            2        1 SYSDBA           N      A
or even this:
     select * from bug_assigned where project is null;
      
          PROJECT     MJR     MNR     RLS     BLD           ID PRIORITY ENTERED_BY                      CLOSED STATUS
     ============ ======= ======= ======= ======= ============ ======== =============================== ====== ======
      
                0       0       0       0       0            2        1 SYSDBA           N      A
Here all the null values as a result of the left outer join are presented as zeros. This is a case using one column to demonstrate even clearer the bug:
     select project
     from bug_assigned
     where project is null;
Produces a zero as the result. The engine seems to recognize that the value is NULL so it honors the WHERE clause, but it returns zero. The view is very simple to be considered a boundary case.

225218 NULLs always at the tail Confirmed Bug
 
According to the standard, it's up to the db vendor where NULLs should be, either at the tail or at the head of an ordered recordset. In IB, when you order ASC (default) on a field with NULLs, they go to the tail. That's a vendor decision. However, the engine must be consistent and in this case, it doesn't: if you order DESC on the same fields, NULLs will appear at the tail, too. One of the answers should be changed.

219525 No current record for fetch operation Confirmed Bug
 
     SELECT * FROM view_det
     INNER JOIN view_inv ON view_det.invcod=view_inv.invcod
DOESN'T WORK - No current record for fetch operation. ... and neither will:
     SELECT * FROM view_det, view_inv
     WHERE view_det.invcod=view_inv.invcod
If you watch the query plan generated by the failing statement, you'll notice it's really big... no surprise since it involves a join of views that in turn are based on other joins. The workaround is to convert
     SELECT * FROM view_det
     JOIN view_inv ON view_det.invcod=view_inv.invcod
to become
     SELECT * FROM view_det
     JOIN view_inv ON view_det.invcod-view_inv.invcod=0
or
     SELECT * FROM view_det
     JOIN view_inv ON view_det.invcod+0=view_inv.invcod
or other variations that fool the optimizer by forcing it to a full scan to do the join. The original statement should work, so this is a bug and the same kind of bug that IB5.X suffered from.

<For full details see original bug report>

221921 ORDER BY has no effect Confirmed Bug
 
Take the following example of a self-referential table and a sproc that returns the children of a specified item:
     create table ExampleTable (
       code integer			not null primary key,
       name varchar(100)		not null unique,
       parent integer,
      
       foreign key (parent) references ExampleTable(code)
     );
      
     /* Children result is not null if this item has it's own children */
     set term !! ;
     create procedure ChildrenOfItem(par integer) returns (code integer,children integer) as
     begin
       for select
          MainTypes.code, Min(ChildTypes.code)
          from ExampleTable MainTypes
          left join ExampleTable ChildTypes on MainTypes.code = ChildTypes.parent
          where MainTypes.parent = :par
             or (MainTypes.parent is null and :par is null)
           group by MainTypes.code
           into :code,:children
       do
          suspend;
     end!!
     set term ; !!
      
     insert into ExampleTable values (0,'A',null);
     insert into ExampleTable values (1,'AA',0);
     insert into ExampleTable values (3,'AB',0);
     insert into ExampleTable values (4,'AC',0);
     insert into ExampleTable values (2,'AD',0);
      
     select * from ChildrenOfItem(0);
Gives: 1,2,3,4 as you would expect
     select * from ChildrenOfItem(0) inner join ExampleTable on ChildrenOfItem.code = ExampleTable.code
     order by name;
Gives: 'AA','AD','AB','AC' even though it is order on name!! Codes are still 1,2,3,4
HOWEVER, in this example, changing it to ORDER BY NAME DESC correctly returns AD,AC,AB,AA

In my real system however, neither ORDER BY NAME or ORDER BY NAME DESC has any effect

225283 ORDER BY on a VIEW turns values in fields into NULL Confirmed Bug
 
Consider a database with 5 tables and a couple of views, one of those views is called v_observation. Consider two queries
     select * from v_observation
     select * from v_observation order by iobservationagree desc
These two queries return different (!) results. And not just the order.... It seems Firebird has trouble dealing with NULL values that are returned and, in the second case, completely omit the infomation retrieved from the database.

430509 ORDER BY works wrong with collate PT_PT Initial Bug
 
Consider,
     CREATE TABLE STOCKS (
       MNEN	        INTEGER NOT NULL,
       ACTIVO	VARCHAR(50) CHARACTER SET ISO8859_1 COLLATE PT_PT,
       CONSTRAINT PK_STOCKS PRIMARY KEY (MNEN) );
having the values:

1, BA
2, BES
3, BCP
4, BA Pref.
5, Banif

doing
     SELECT ACTIVO FROM STOCKS ORDER BY ACTIVO
gives:

BA
Banif
BA Pref.
BCP
BES

447002 Optimisation on subselects Initial Bug
 
The InterBase Optimizer does not properly utilize indexes on sub-selects containing IN. Example: (Using - Employee.gdb)
      select *  from employee
        where dept_no in
         (select dept_no from department where department = Marketing);
Produces the plan:
PLAN (DEPARTMENT INDEX (RDB$4,RDB$PRIMARY5))
PLAN (EMPLOYEE NATURAL)

You can fool the optimizer into using the appropriate index by using the following trick.
      select *   from employee
        where dept_no  0 /* something that is always true */
        and dept_no in
          (select dept_no from department where department = Marketing);
Produces the correct plan:
PLAN (DEPARTMENT INDEX (RDB$4,RDB$PRIMARY5))
PLAN (EMPLOYEE INDEX (RDB$FOREIGN8))

213460 Registering Events w/certain configuration crashes IB Server As Designed/Pitfall
 
With a certain server network configuration, registering an event will lock up the client and lockup the server (requiring a reboot if it runs as a service, or a process kill if it runs as an application (the guardian does not detect it's lockup)) *if* the client is accessing the server through the internet (if it comes through the local lan, then it's fine).

Configuration Description To Cause Bug

The above system has only one nic card in it. This card was assigned two IP's, the first being a 192.168.0.x (local network), and the second being it's internet address. A gateway for the NIC card was also set, in addition to IP Forwarding (which was removed later).

This configuration, while not considered the best, is perfectly legal, and works effectively with all the different servers run on it (MS SQL Server, ftp and web servers, etc.), both accessed from the internet and the local intranet.

It is only when a client attempts to register events when connected through the internet to the server system that the lockups occur. Otherwise, if the system is on the intranet, the access runs fine.

Fix

By setting the internet IP first, then having the intranet ip set in the advanced screen (under the internet IP), the problem is resolved (a reboot will be required after changing the configuration).

233025 Server hangs when executing Stored Proc more than once Confirmed Bug
 
When executing a SP inside a loop that accepts input parameters, the server hangs on the second iteration if the statement is not unprepared and re-prepared between iterations. This is an old bug which goes back to v. 5.x as well.

Note that, if you add a SUSPEND statement at the end of the SP and return a dummy parameter, you can multi-call the SP with SELECT instead of EXECUTE without the need to do the unprepare/prepare when passing subsequent sets of inputs.

223060 Slow processing of GREATER-THAN operator Initial Bug
 
Suppose you have table
       CREATE TABLE tab (field INTEGER  CHECK(field=0) );
       CREATE INDEX idx ON tab (field);
with lots of rows where field=0.
When you execute these two statements
       SELECT * FROM tab WHERE field = 1
       SELECT * FROM tab WHERE field  0
they both will return the same result set, they both will use the same plan, however the second one (with ) will be much slower. The difference is caused by internal processing of = and clauses when using indexes.

When you execute
       SELECT * FROM tab WHERE field = 1
IB will use index to locate all values =1, o.k.

When you execute
       SELECT * FROM tab WHERE field  0
IB will use index to locate all values =0 !!!
i.e. ALL rows from our test table !!!

Why nobody noticed it ?
- for columns with more even distribution of values the speed difference is minimal
- IB usually evaluates condition twice
1. it first locates row by index (not always correctly as you can see)
2. after fetching row it evaluates the condition again (in this case it discards rows where field=0, that should have been filtered out by index)

How can you verify this theory ?
- start (W)ISQL and update one row where value is 0.
Do not commit.

- start another (W)ISQL and start transaction
SET TRANSACTION READ COMMITTED NO RECORD_VERSION NO WAIT

Now, first execute faster query (where field = 1). You will get correct answer. Then execute slow query (where field 0). You will get lock conflict error.

It means that IB tries to internally fetch row that does not meet criteria (value0) and that should have been skipped when using index properly.

213859 Subquery connected with 'IN' clause Confirmed Bug
 
Given a table test which has the colums id integer (unique) and num integer. Insert some records (~40.000 in my case). Most of the numbers in column num are distinct, only some are two ore three times repeated.

The following query fails:
     Select id, num from test where num in (select num from test group by num having count(num  1))
What is expected: those numbers WITH ID's which occur more than one time in the database.

Note: * Each query for it's own succeeds.
* Preparing column num in a way that select num from test group by num having count(num 1) would return only one row and rewritting the statement as Select id, num from test where num = (select num from test group by num having count(num 1)) succeeds too.

Tested with MS Access, MS-Sql, Oracle using the same data, the query finished within three seconds.

409769 UDF argument can't be query-parameter Initial Bug
 
       SELECT
          Field1, Field2, ... , UDF1(Field1, ?Param1)
       FROM
          TABLE1
doesn't work - message is unknown data type

221649 Unique index allowed on NULLABLE field Confirmed Bug
 
     create table mau(a int);
     commit;
     create UNIQUE index idx_mau on mau(a);
     commit;
Whether this was left as a transition from Paradox (that accepts NULL PKs) or it's an oversight is what I want to confirm.

As a comparation, you cannot declarate a PK or UNIQUE constraint if you don't include the NOT NULL clause on the affected field(s), so the underlying automatic index for such constraint will be always on non-nullable column(s).

211781 Win32: Server don't close thread handles Confirmed Bug
 
Allocation location is in SVC_start, last param 'service-svc_handle'.

233644 cannot specify PLAN in UPDATE statement Confirmed Bug
 
I need to set FULLNAME=NAME for all records in company where fullname IS NULL or fullname = '', so I wrote the following statement:
     UPDATE company cp
       SET fullname= (SELECT name FROM contact ct WHERE ct.id=cp.contactkey)
       WHERE cp.fullname IS NULL OR cp.fullname = '';
Both tables contains ~40K records so the request hangs my machine. After reboot I checked the plan and it was PLAN(company NATURAL, contact NATURAL).

I tried to set PLAN for entire UPDATE statement or only for SELECT sub-query but in both cases I received error message Invalid SQL or something like this.

459059 index breaks = ANY result Initial Bug
 
Using Martin Gruber's book, I've found that index can break returning result of ANY subquery.
     CREATE TABLE CUSTOMERS (
         CNUM INTEGER,
         CNAME CHAR(10),
         CITY CHAR(10),
         RATING INTEGER,
         SNUM INTEGER);
      
     INSERT INTO CUSTOMERS VALUES (2001, 'Hoffman', 'London', 100, 1001);
     INSERT INTO CUSTOMERS VALUES (2002, 'Giovanni', 'Rome', 200, 1003);
     INSERT INTO CUSTOMERS VALUES (2003, 'Lui', 'San Jose', 200, 1002);
     INSERT INTO CUSTOMERS VALUES (2004, 'Grass', 'Berlin', 300, 1002);
     INSERT INTO CUSTOMERS VALUES (2006, 'Clemens', 'London', NULL, 1001);
     INSERT INTO CUSTOMERS VALUES (2008, 'Cisneros', 'San Jose', 300, 1007);
     INSERT INTO CUSTOMERS VALUES (2007, 'Pereira', 'Rome', 100, 1004);
      
     SELECT *
     FROM Customers c
     WHERE not c.rating  = any
        (SELECT r.rating
        FROM Customers r
        WHERE r.city = 'San Jose');
When there is no index on RATING field all OK, and result is the same when not c.rating = ANY is changed to c.rating ALL (this is normal behavior according to the book and SQL standard).
     CNUM	CNAME	CITY	RATING	SNUM
     2001	Hoffman	London	100	1001
     2007	Pereira	Rome	100	1004
But if index on RATING is added
     CREATE INDEX BYRATING ON CUSTOMERS (RATING);
things goes wrong, and not c.rating = any starts using index and producing wrong results:
PLAN (R INDEX (BYRATING))
PLAN (C NATURAL)
     CNUM	CNAME	CITY	RATING	SNUM
     2001	Hoffman	London	100	1001
     2006	Clemens	London		1001
     2007	Pereira	Rome	100	1004
middle record have RATING value = NULL.

Workaround is only one - use c.rating ALL instead of ANY. It does not use index and returns correct result. But this is not applicable for all cases.

408272 infinite insertion cycle Confirmed Bug
 
The execution of the following query will result in the engine going into an infinite insertion cycle:
     insert into MyTable select * from MyTable

Category: DSQL

SF ID Description Group/Status  
452120 CREATE VIEW ignores PLAN Initial Bug
 
When you include an explicit plan in a CREATE VIEW statement, the plan is silently ignored.
     create table a (
     	b integer not null
     );
     create index a_b on a(b);
      
     create view view_a(b) as
       select b
       from a
       where b  2
       plan (a natural);
     commit;
      
     set plan;
     set echo;
     select * from view_a;
     select b from a where b  2
       plan (b natural);
     commit;

444763 Empty column names with aggregate funcs Initial Bug
 
If you execute this statement the column name of the inner select is empty:
     select (select count(1) from rdb$database) from rdb$database
I don't know if this is a bug or just a limitation but it seems that this bug(limitation) is somehow related to #222476. The difference is that it happen with all aggregate functions(count, min, max, sum, avg) and also in dialect 1.

444081 FOR SELECT firs SUB SELECT is wrong Initial Bug
 
      FOR SELECT
       DO BEGIN
         SELECT xxx FROM WHERE yyy in (SELECT xxx)...; - It's wrong
       END

223516 Missing types in rdb$types. Confirmed Bug
 
The Language Reference describes rdb$fields.rdb$field_type values which are missing from the the RDB$Types table, the missing values are:
D_FLOAT = 11
GROUP = 12
ROLE = 13
INT64 = 16

451944 Trigger Activate/Deactivate increases meta counter Confirmed Bug
 
Activating/Deactivating trigger should not increment the metadata counter.

449011 Unique key and char type in SQLDialect 3 Initial Bug
 
Unique key and char type in SQL Dialect 3 If to create a database with use SQL Dialects 3, to the line data there is a following:

Example of the table:
     CREATE TABLE LABELS (
       CODE VARCHAR (13) NOT NULL,
       VALUT SMALLINT NOT NULL,
       PRIMARY KEY (CODE));
Both columns should not be equaled NULL and primary (unique!) key - CODE.

At addition in a database of a line (for example CODE = ABC and VALUT=1) all is normal,

But if to remember changes, then it is possible to appropriate(give) to a field CODE=NULL!!! - and it NOT a ZERO INDEX, and primary!

Category: Documentation

SF ID Description Group/Status  
458863 Default column(s) for REFERENCES Initial Bug
 
In Language Reference, there is written for REFERENCES keyword used in CREATE TABLE and ALTER TABLE commands:
     col_constraint = [CONSTRAINT constraint] ...
       REFERENCES other_table [( other_col [,
     other_col ...])] ...
REFERENCES Specifies that the column values arederived from column values in another table; if you do not specify column names, InterBase looks for a column with the same name as the referencing column in the referenced table.

Current (and I think that correct) behaviour is that if you do not specify column names, primary key from referenced table is used.

Category: GBAK

SF ID Description Group/Status  
471674 Direct file access with SuperServer Initial Bug
 
command report:
lock manager error
inconsistent lock table version number; found 114, expected 14

After reading documentation about Security on CS and SS I thing, that SS not support direct file access, but why gbak (and other command line utilities) report lock manager error.

When FirebirdSS start, it does not create IPC semaphores. After execute gbak with direct file access, IPC semaphores is created, but not removed.


429594 GBAK UDF in 'COMPUTED BY' field Initial Bug
 
GBAK restores tables and views before UDFs. If table or view contains an UDF in 'COMPUTED BY' filed, GBAK can't restore it.

417567 GBAK can't restore database after backup Confirmed Bug
 
Sometimes GBAK can't restore database from successfull backup. It can't resolve dependecies between triggered views.

424307 GBAK overwrites BK file Initial Bug
 
GBAK overwrites BK file before starting back up process. So if you have database with valuable data and backup copy of it. And your database file gets corrupted so GBAK cannot proceed and you will execute command gbak -b database backup

gbak will erase backup file then checks database file and after encountering error will stop process so you will loose your backup file forever.

In my example I had GDB file and BK. GDB file was in 5.6 format and server was of 6.0. I forgot for version of GDB file and run gbak. It deleted my BK file and raises error message that GDB of wrong ODS version.

The right behavior would be to overwrite BK file only after successfull process is done.

228431 gbak cannot restore backup made by IB v5 Confirmed Bug
 
gbak under Linux is coredumping while loading a database backup made by gbak v5. the bug is deterministic and does not concern the official borland gbak for v6 and is related to the database content - only one of 3 different database backups generated the bug.

Database in question:
about 150MB, no triggers, no stored procedures - pure data but about a dozen of generators.

Returning to official gbak the bug disappeared.

Category: GPRE

SF ID Description Group/Status  
416228 gpre generates invalid isc_vtov calls Confirmed Bug
 
gpre generates the following incorrect code for tan.e in TCS (line 6303+):
           isc_vtov (isc_342.isc_345, run_name, sizeof (run_name));
           run_count = isc_342.isc_343;
           isc_vtov (isc_342.isc_346, max_date, sizeof (max_date));
           isc_vtov (isc_342.isc_347, min_date, sizeof (min_date));
The second parameter to isc_vtov is the incorrect type. This causes the compiler in Darwin to generate an error message and not compile the tan.c file.

Category: IBConsole (No Longer Used)

SF ID Description Group/Status  
457230 Aritmetic Exception on Object Exception Initial Bug
 
When a Exception have Á or another Brasilian language symbol and select object Exceptions on IBConsole under Database raise a exception Arithmetic exception, numeric overflow, or string truncation Cannot transliterate character between character sets

Category: ISQL

SF ID Description Group/Status  
223513 Ambiguity between tables and views in isql's SHOW commands. Confirmed Bug
 
Consider,
     SQL create table t(a int);
     SQL create view v as select a from t;
     SQL show tables;
            T                 V
Notice both T and V are shown, but only T should be shown. One can argue that a view is a virtual table, etc.

Now the next item, this shouldn't work:
     SQL show table v;
     A                               INTEGER Nullable
     View Source:
     ==== ======
      select a from t
This also shouldn't work:
     SQL show view t;
     A                               INTEGER Nullable

223126 Misplaced collation when extracting metadata with isql Confirmed Bug
 
There is a bug that if you override a domain's constraints or default and also override the collate the collate will be extracted before the default or constraint.

225219 isql -a: wrong order with domains based on table's fields Confirmed Bug
 
According to the documentation: «The CHECK constraint in a domain definition sets a dom_search_condition that must be true for data entered into columns based on the domain. The CHECK constraint cannot reference any domain or column.»

So, this should be banned:
     create domain d_ontable int
     check(value(select rdb$relation_id from rdb$database))
Now what happens with a restore if the domain's check constraint is based on a user table? (And not a system table, where it could work eventually.)

Markus Kemper discovered this issue initially but he wrote that isql was unable to extract info from it, because he though it was an isql limitation. This is only geeky detail or joke, a bit unrelated with the previous: please see how useful is this domain:
     create domain value_gt_value int check(valuevalue)

450404 isql uppercases role in the command line Confirmed Bug
 
I think example should be enough clear: when isql is invoked and the role is passed in the command line, it always uppercases the role:

H:\ibdev\fbbuild\interbase\dsqlisql
c:/proy/fbtest.gdb -u cvc -p pw -r for cvc
Database: c:/proy/fbtest.gdb, User: cvc, Role: FOR CVC
SQL

As you can see, isql puts the message with the role in uppercase and indeed the engine received it uppercased. Notice that double quotes weren't interpreted as don't change the input parameter.

However, when doing the connection as a command, the role is processed correctly:

H:\ibdev\fbbuild\interbase\dsqlisql
Use CONNECT or CREATE DATABASE to specify a database
SQL connect c:/proy/fbtest.gdb user cvc password pw
role for cvc;
Database: c:/proy/fbtest.gdb, User: cvc, Role: for cvc
SQL

Now, isql reflects the unchanged role and the engine receives it correctly.

Whether this anomaly exists for some purpose I don't know, but I consider it a bug. Both ways to work with isql should be equivalent when facing identifiers surrounded by double quotes.

Category:

Installation - Server
SF ID Description Group/Status  
224130 Install conflict with Interbase Confirmed Bug
 
I had previously installed the ib_client package. I installed firebird. Things got very confused. For example here are the registry entries:

[HKEY_LOCAL_MACHINE\Software\Borland\InterBase\CurrentVersion]
UseCount=dword:00000001
RootDirectory=C:\\Program Files\\Borland\\InterBase\\
Version=WI-V6.0.0
DefaultMode=-r
ServerDirectory=:\\Program Files\\firebird\\
GuardianOptions=1

Notice that it was installed into C:\Program Files\Firebird but the root directory is C:\Program Files\Borland\Interbase. The RootDirectory entry was apparently left over from my install of ib_client. After I thoroughly uninstall Firebird and Interbase and re-install Firebird, the RootDirectory is C:\\Program Files\\firebird\\ which is probably correct.

The normal procedures of installing software under Windows is that either [a] Firebird is Interbase so I should be able to install over an old version, or [b] Firebird is not Interbase so I should have no problem installing both on the same machine. But in may ways Firebird still thinks it is named InterBase and gets confused.

We should anyone installing Firebird to uninstall any version of InterBase, server or client, before installing Firebird. If possible, the Firebird install should check to see if InterBase is installed, and halt with an error message if so.

230361 Install erases all users and passwords Initial Bug
 
Installing Firebird over top of an existing installation of Firebird replaces ISC4.GDB, thereby wiping out the existing list of usernames and passwords.

224333 xinitd in Mandrake 7.2 Confirmed Bug
 
Mandrake 7.2 can be setup to use xinetd instead of the regular inetd in which case the /etc/inetd.conf file is not the right way to setup the server. Instead a file needs to be placed in /etc/xinet.d with basically the same information as goes in inetd.conf.

Category: InterClient

SF ID Description Group/Status  
212656 ResultSet ignores column labels Initial Bug
 
- applies to InterClient1.6 and InterClient2.0

- details and a fix are here:
http://www.egroups.com/message/IB-Java/42

233063 Scale error in getBigDecimal Initial Bug
 
1) In IBConsole
     create table bug(bug integer)
     insert into bug values (10)
2) In Java
     conn = DriverManager.getConnection(......);
     statement = conn.createStatement();
     resultSet = statement.executeQuery(select * from bug);
     while (resultSet.next()) {
         System.out.println(resultSet.getBigDecimal(1, 5));
     }
Output is 0.00010 !

Explanation:
Bug in class ResultSet, method getBigDecimal
     synchronized public java.math.BigDecimal getBigDecimal (int column, int scale) throws java.sql.SQLException
       {
     ................................
         case IBTypes.INTEGER__:
           return java.math.BigDecimal.valueOf ((long) getRowData_int (column-1), scale); // !!! but first parameter is unscaled(!) value !!!
     ................................
Solution:
     return java.math.BigDecimal.valueOf ((long) getRowData_int (column-1)).setScale(scale, java.math.BigDecimal.ROUND_HALF_EVEN);

227414 Sometimes Interbase/Interserver stop grant connections Confirmed Bug
 
Sometimes I have this problem while asking for Interbase connection, sometimes releasing it. I cannot understand the exact way to reproduce it, but I attached a simple java program that loops until the error presents. If you want to try to reproduce it execute three of four instances of the program at the same time.

The error is java.lang.VerifyError.

I'm using:
- Interbase 6.0.1
- Interclient 2.0 beta (I tried IC1.6 but with the same result...)
- Windows 2000 Professional
- Sun JVM 1.3

The same program works fine, without any error, for hours and hours, if I use the latest trial version of Easysoft ODBC driver

212653 Statement.getFetchSize not supported Initial Bug
 
- applies to InterClient1.6 and InterClient2.0

- Statement.getFetchSize throws a DriverNotCapableException while Statement.setFetchSize _is_ supported.

- how to fix: <sniped, see bug report for details>

212651 Statement.setMaxRows has no effect if fetchSize==0 (default) Initial Bug
 
- applies to InterClient1.6 and InterClient2.0

- Statement.setMaxRows (PreparedStatement.setMaxRows respectively) have no effect if no fetchSize has been defined (fetchSize is 0 by default). In this case a ResultSet will return all rows of a query, even if the rowcount exceeds maxRows.

- how to fix: <sniped, see bug report for details>

466553 UnavailableInterBaseServerException Initial Bug
 
There is a serious bug in Interclient when getting a connection to Interbase/Firebird, the bug has been reported in various IB/FB newsgroupst.

The bug is that in a multi connection enviorement after some time Interclient throws UnavailableDatabaseExceptions. Than no new connection can be established. Users that have connections can work as normal.

If some connections are closed than new connections are established again -- at the moment IB/Firebird with Interclient is not usable with multi-connections.

I have written a test program that shows the bug after some time. I tested it on Win2000SP2 and on WinNTSP6 with FirebirdBeta2/OpenSourceInterbase and Interclient 2.0.2 from the trail with the patch.

The exception is thrown in the method remote_ATTACH_DATABASE() of the Class Connection where recvMsg.get_SUCCESS () returns false and so the following exception is thrown.
(interbase.interclient.UnavailableInterBaseServerException: [interclient][interbase] unavailable database)

<For test code see original bug report>

425880 build.xml bug on Solaris 7 Initial Bug
 
When you try to build the InterClient 2.0 with ANT, you get the linker problem:
     link.cpp:
     [execon] Undefined first referenced
     [execon]  symbol in file
        
     [execon] /home/rocky/src/interclient/20/build/interserver/NetTCP.o  (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
     [execon] /home/rocky/src/interclient/20/build/interserver/NetTCP.o  (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
     [execon] /home/rocky/src/interclient/20/build/interserver/NetTCP.o  (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
     [execon] /home/rocky/src/interclient/20/build/interserver/NetTCP.o  (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
     [execon] /home/rocky/src/interclient/20/build/interserver/NetTCP.o  (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
This can be solved by adding the argument arg value=-lsocket/ to the execon ... command in the link.cpp target.

213428 timeout in ib doesn't notify interclient Initial Bug
 
After a connection has been idle for a certain amount of time Interbase disconnects without InterClient being notified.

This causes an exception the next time any kind of remote operation is performed, and makes the Connection worthless ( for obvious reasons ). I think would should implement a 'reconnect' parameter in the Connections parameters to specify whether or not we want it to automatically reconnect if a dead connection is detected. This is already being done in MySQL's JDBC driver. Since JDBC doesn't have a detection method to check the validity of the connection, this is the only option I see as pheasible.


Category: Linux ports

SF ID Description Group/Status  
469572 1.0/Beta 2: inst.script broken for Linux Initial Bug
 
The install scripts (install.sh, and scripts/CS*.sh) are broken.

1) The have the /opt/... path hardcoded. This directory is not part of the linux standard filesystem and many distributions (including slackware 8.0) don't create /opt. Won't it be better to simply ask the user for the install root directory - which you should be doing even if /opt existed ?

2) One of the scripts has '/usr/bin/mkpasswd' harcoded. That command is under /usr/sbin/ in linux. Why not just use 'mkpasswd', since we are installing under root, we get both /usr/bin and /usr/sbin, so you don't have to hardcode either.

Category: Security Issues

SF ID Description Group/Status  
229237 Blank passwords poorly supported Confirmed Bug
 
The tools like isql poorly support having a user with a blank password. You are allowed to create one but then you can't ever connect using isql if you create the user that way. The obvious option of trying -p for the password doesn't work and is thrown out by the argument parser. Not supplying a password also doesn't work.

The isql tool should allow -p for the password and try to connect using a blank password in that case.

229894 Client program can log on as any user. Confirmed Bug
 
The client program by manipulation of the user_string property can log onto the server as any user including sysdba.

The usage of the user_string passed from the client to the server in the form name:uid:gid and is used as the default logon userid if no explicit user name/password is supplied. This field is accepted without question by the server.

If the user_string is blank when passed to the server (as apparently is the case for BDE), then (linux surver anyway) defaults the user to the geteuid() of the server process.

222375 Grants overwrite previous rdb$security_classes entries Confirmed Bug
 
First, let me say that a clarification is need. If Firebird can rely solely on rdb$user_privileges, then this report is not critical. Otherwise, the results of records being overwritten silently on rdb$security_classes is an issue. The following is an almost unedited copy from an article I wrote on the NG:

- Create a table with 31-byte name.
- Create a second table with the same name, except that it differs only in the last, 31th character.
- Grant permissions to userA on the first table and to userB on the second table.
- Go to see rdb$user_privileges and you'll see your entries as they should be.
- Go to rdb$security_classes: with rdb$ as a prefix, 31-4=27, oh what a brilliant person I am.
Here's your 27-byte limitation: what happened to this table?
Both entries were mapped to the same record, same security class! As a result of that, the second GRANT overwrote the information for the first one, because rdb$security_classes.rdb$security_class used sql$table_name hence the last 4 bytes were ignored. Feature? Undocumented limitation? Bug?

So, what LangRef says could be refurbished as: "Some objects, such as security class names, are restricted in practice to 27 bytes in length."

The final part comes from Ivan Prenosil: Or perhaps something like "Table names should not exceed 27 bytes, otherwise you can expect problems with privileges...."

223128 SYSDBA can grant non existent roles Confirmed Bug
 
IB doesn't check the user in a GRANT statement probably because the db can be moved to another server where such user is defined, since the information is stored in isc4.gdb only.

But why would IB allow SYSDBA to grant no existent roles to users? For example, this is accepted:
     grant anything to alice
However, anything doesn't exist in rdb$roles but rdb$user_privileges logs a role granted to alice.

In contrast, a non-privileged user can't grant a role that doesn't exists. So I wonder is this is a bug or a feature. Why would SYSDBA need to bypass role checking when grating roles to users?

423810 User Password length Initial Bug
 
try to connect to a database with user=SYSDBA and passord=masterke It seems that password legth is truncated to 8 char. Looking in isc4.gdb, PASSWD ( in table users) is defined as PASSWD AS VARCHAR(32) CHARACTER SET OCTETS;.