Subject | COLLATE PXW_PLK kills the ibserver |
---|---|
Author | peter_datacomp <p.borelowski@datacomp.co |
Post date | 2003-02-04T13:37:03Z |
It looks like a bug. Here are the details:
I have a simple database and a query that reproducibly cause the
ibserver to crash.
The database metadata is:
CREATE TABLE ABC
(
ID INTEGER NOT NULL,
NAME VARCHAR(512) CHARACTER SET WIN1250 COLLATE PXW_PLK,
CONSTRAINT PK_ABC PRIMARY KEY (ID)
);
The data itself is:
INSERT INTO ABC
(ID, NAME)
VALUES
(1, 'Opracowanie programu autorskiego i przeprowadzenie zajec w sem.
letnim 01/02Opracowanie programu autorskiego i przeprowadzenie zajec
w sem. letnim 01/02Opracowanie programu autorskiego i przeprowadzenie
zajec w sem. letnim 01/02Opracowanie programu autorskiego i
przeprowadzenie zajec w sem. letnim 01/02Opracowanie programu
autorskiego i przeprowadzenie zajec w sem. letnim 01/02Opracowanie
programu autorskiego i przeprowadzenie zajec w sem. letnim 01/02');
Note 1: The string consists of 456 characters, and it is a
concatenation of 6 same strings each 76 character long.
Note 2: The string contains only ASCII characters
(there are no WIN1250 specific characters).
The query is:
SELECT ID
FROM ABC
ORDER BY NAME;
Execution of that query produces an error message and kills the
server.
Under isql.exe the error message is:
Statement failed, SQLCODE = -901
connection lost to database
Under IBConsole version: 1.0.1.344 for Windows 9x the error message
is:
unassigned code on line 1 : SELECT ID
FROM ABC
ORDER BY NAME
invalid database handle (no active connection)
I use NI-T1.5.0.671 Firebird 1.5 Alpha 1 on Windows 98. The same
happens when Interbase of various versions is run. I used InterBase
Server WI-V6.0.0 among others.
Some modification of the string are possible and the error still
occures. Others prevent the error. I cannot see any pattern. For a
constant string the error repeats.
The error seems connected to COLLATE and ORDER BY. The ID column and
PRIMARY KEY are also necessary for the error to occure. Another query
that causes the problem is:
SELECT DISTINCT NAME
FROM ABC;
which again implies comparision of data in NAME (although there is
only one row in the table).
--
Piotr
I have a simple database and a query that reproducibly cause the
ibserver to crash.
The database metadata is:
CREATE TABLE ABC
(
ID INTEGER NOT NULL,
NAME VARCHAR(512) CHARACTER SET WIN1250 COLLATE PXW_PLK,
CONSTRAINT PK_ABC PRIMARY KEY (ID)
);
The data itself is:
INSERT INTO ABC
(ID, NAME)
VALUES
(1, 'Opracowanie programu autorskiego i przeprowadzenie zajec w sem.
letnim 01/02Opracowanie programu autorskiego i przeprowadzenie zajec
w sem. letnim 01/02Opracowanie programu autorskiego i przeprowadzenie
zajec w sem. letnim 01/02Opracowanie programu autorskiego i
przeprowadzenie zajec w sem. letnim 01/02Opracowanie programu
autorskiego i przeprowadzenie zajec w sem. letnim 01/02Opracowanie
programu autorskiego i przeprowadzenie zajec w sem. letnim 01/02');
Note 1: The string consists of 456 characters, and it is a
concatenation of 6 same strings each 76 character long.
Note 2: The string contains only ASCII characters
(there are no WIN1250 specific characters).
The query is:
SELECT ID
FROM ABC
ORDER BY NAME;
Execution of that query produces an error message and kills the
server.
Under isql.exe the error message is:
Statement failed, SQLCODE = -901
connection lost to database
Under IBConsole version: 1.0.1.344 for Windows 9x the error message
is:
unassigned code on line 1 : SELECT ID
FROM ABC
ORDER BY NAME
invalid database handle (no active connection)
I use NI-T1.5.0.671 Firebird 1.5 Alpha 1 on Windows 98. The same
happens when Interbase of various versions is run. I used InterBase
Server WI-V6.0.0 among others.
Some modification of the string are possible and the error still
occures. Others prevent the error. I cannot see any pattern. For a
constant string the error repeats.
The error seems connected to COLLATE and ORDER BY. The ID column and
PRIMARY KEY are also necessary for the error to occure. Another query
that causes the problem is:
SELECT DISTINCT NAME
FROM ABC;
which again implies comparision of data in NAME (although there is
only one row in the table).
--
Piotr