""Henner Kollmann"" <Henner.Kollmann@...> wrote in message
news:000b01c1cf3c$e94587c0$1e5562c1@......

> No, do not help.
> Checked it with the debugger:=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.

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

/* 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?

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.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing