Subject | Re: [ib-support] Problems with gbak |
---|---|
Author | Claudio Valderrama C. |
Post date | 2002-03-21T04:27:45Z |
""Henner Kollmann"" <Henner.Kollmann@...> wrote in message
news:002201c1cfe4$47d1f600$1e5562c1@......
translated by GPRE into BLR. But here, due to the goal that needs to be
achieved, the binary commands are assembled directly by gbak.
for some field and this raised the length from 46 to 48.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing
news:002201c1cfe4$47d1f600$1e5562c1@......
>In other places, you don't use blr_buffer. There's a GDML command that
> 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)))
translated by GPRE into BLR. But here, due to the goal that needs to be
achieved, the binary commands are assembled directly by gbak.
> > Watch this chunk, what's the value of offset? And length?Nothing special. The code in that function found that it needed an alignment
>
> record_length = 46;
> length = 48;
for some field and this raised the length from 46 to 48.
> >Not for now. We need to know why the engine itself is apparently stuck.
> Make the copy, drop all other tables. Problem is repeatable.
> No other idea than to debug the engine?
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing