Hi Ann,

Thanks for taking this issue serious.

1. I'm kinda running out of time, so I'm continuing my search towards a
workable sollution. Reading your reply forces me to find an intermediate
workaround. Currently I'm retesting this with RC8 and a slightly altered
table. I've dropped the primary key definition to prevent it creating an
index simultaniously. Afterwards (if all works well) I can create an
additional unique index to have the same behaviour.

2. Concerning the data that I put in:
create table q
(
id integer not null, /* roughly 140.000
variations */
moment timestamp not null, /* running from the year 1997 till
2003 */
l numeric(16,4), /* almost always filled with a
positive value */
v integer, /* almost always filled with a
positive value */
o numeric(16,4), /* almost always filled with a
positive value */
h numeric(16,4), /* if l is entered, so is
h, and lo */
lo numeric(16,4),
b numeric(16,4), /* if entered the a is also
filled, but mostly empty */
a numeric(16,4),
t integer, /* almost always filled with a
positive value (0..7) */
rowkey integer not null, /* generator value to
uniquely identify each row */
primary key (rowkey) /* (I've removed the primary key definition
to add a unique index later on */
);

I hope this helps to find the bug in Firebird. If there's anything else
I need to explain or if I encounter something else, I'll report it to
this list.

Kind regards,
Marco Wobben

Ann Harrison wrote:

> First, the error "pointer page vanished from DPM_next" or any other
> error that includes the name of an internal routine - of the format
> XXX_xxxxx - is a bug. <...snip...> Let me try to reproduce the error
> based on your specifications. Do you put any particular data in the
> table when you load it - other than the not null fields, of course?
>
> Regards,
>
>
> Ann