Hello Claudio,

> > No, do not help.
> > Checked it with the debugger:=20

What do you mean with :=20 ???? :-)

> >
> > Never returns from isc_start_request(...) in put_data, backup.c?
>
> What's the specific request that's sent in this case? There
> should be some command inside comments in the C file, some
> lines before. Ah, no, in this case, there's no high level
> GDML code, it's all done in BLR even in the E file that's
> preprocessed to generate the C file you're reading.

Request is to put data for the large table. I found only one place where
isc_start_request is called in put_data:

/* Compile request */

request = NULL;
blr_length = blr - blr_buffer;
if (isc_compile_request (status_vector,
GDS_REF (tdgbl->db_handle),
GDS_REF (request),
blr_length,
GDS_VAL (blr_buffer)))
{
BURP_error_redirect (status_vector, 27, NULL, NULL);
/* msg 27 isc_compile_request failed */
isc_print_blr (blr_buffer, NULL_PTR, NULL_PTR, 0);
}

BURP_FREE (blr_buffer);
records = 0;
BURP_verbose (142, relation->rel_name, NULL, NULL, NULL, NULL);
/* msg 142 writing data for relation %s */

if (isc_start_request (status_vector,
GDS_REF (request),
GDS_REF (isc_trans),
0))
BURP_error_redirect (status_vector, 28, NULL, NULL);
/* msg 28 isc_start_request failed */

/* Here is the crux of the problem -- writing data. All this work
for the following small loop. */

>
> Watch this chunk, what's the value of offset? And length?

record_length = 46;
length = 48;

>
> /* Finally, make up an EOF field */
>
> STUFF (blr_short); /* eof field */
> STUFF (0); /* scale for eof field */
> record_length = offset; <============
> eof_parameter = count++;
> eof_offset = FB_ALIGN(offset, sizeof (SSHORT));
> length = (USHORT) (eof_offset + sizeof (SSHORT)); <===
>
> What's the combined length of all your fields in that table?
> If you create that table in an empty db and put some records
> on it, can you see the same problem?

No, i have no problems to insert 4.500.000 records into this table. Here
is the DDL:

CREATE DOMAIN ID_FLD AS
INTEGER
NOT NULL
/* Tables definitions */
CREATE TABLE TBLSTRECKENBELASTUNG (
VONKNOTENNR ID_FLD,
NACHKNOTENNR ID_FLD,
TBLARTNR ID_FLD,
ZAEHLDATUM TIMESTAMP NOT NULL,
INTERVALLSTART INTEGER NOT NULL,
ANZAHLVON INTEGER,
ANZAHLNACH INTEGER);
/* Primary keys definition */
ALTER TABLE TBLSTRECKENBELASTUNG ADD PRIMARY KEY (VONKNOTENNR,
NACHKNOTENNR, TBLARTNR, ZAEHLDATUM, INTERVALLSTART);
/* Foreign keys definition */
ALTER TABLE TBLSTRECKENBELASTUNG ADD CONSTRAINT FK_TBLSTRECKENTEXTE
FOREIGN KEY (VONKNOTENNR, NACHKNOTENNR) REFERENCES TBLSTRECKENTEXTE
(VONKNOTENNR, NACHKNOTENNR) ON DELETE CASCADE;

>
> One thing you can do is create a copy of the db, then drop
> all other tables. If the problem is repeatable in the trimmed
> db, execute gbak in verbose mode and put a breakpoint in
> isc_start_request inside the engine. When gbak shows that
> it's going to write that table "writing data for relation
> <name>" you know the isc_start_transaction that follows is
> the one you should examine step by step.
>

Make the copy, drop all other tables. Problem is repeatable.
No other idea than to debug the engine?

Thanks,
Henner Kollmann