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;.
|
|
|
|
|