On 03/03/14 12:39, Philippe Makowski wrote:
Le 03/03/14 09:30, Philippe Makowski a écrit :
fb3.0 snapshot build fail under Linux since March 1st
this morning output is here : http://fpaste.org/81779/
seems that it is related to gcc version
builds with gcc (GCC) 4.8.2 (Mageia and ArchLinux)
It fails also on ubuntu 14.04 so we wait for Alex commits
gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu4)
On Mon, Mar 3, 2014 at 10:39 AM, Philippe Makowski
pmakow...@ibphoenix.fr wrote:
Le 03/03/14 09:30, Philippe Makowski a écrit :
fb3.0 snapshot build fail under Linux since March 1st
this
On 03/03/14 12:30, Philippe Makowski wrote:
Hi,
fb3.0 snapshot build fail under Linux since March 1st
this morning output is here : http://fpaste.org/81779/
I've fixed it. The only thing I do not understand is how could it be
built by some gcc versions.
Asynchronous cancellation request can be ignored in the case of EXECUTE
STATEMENT and WHEN used together
Key: CORE-4356
URL:
03.03.2014 10:27, Alex Peshkoff wrote:
3.- We have this in restore for rdb$relation_fields:
case att_field_character_length:
field-fld_character_length = (USHORT) get_numeric(tdgbl);
break;
However, as the old comment indicates
SSHORT fld_character_length; // only assigned in
On 02/28/14 21:01, Dimitry Sibiryakov wrote:
Hello, All.
Attached patch gives to isc_dsql_fetch(), isc_dsql_execute2() and
isc_dsql_exec_immed2() ability to work with wide result set.
At the first look this should work. What I do not understand - why not
all functions, using XSQLDA, were
03.03.2014 12:30, Alex Peshkoff wrote:
On 02/28/14 21:01, Dimitry Sibiryakov wrote:
Attached patch gives to isc_dsql_fetch(), isc_dsql_execute2() and
isc_dsql_exec_immed2() ability to work with wide result set.
At the first look this should work. What I do not understand - why not
all
On 03/03/14 15:37, Dimitry Sibiryakov wrote:
03.03.2014 12:30, Alex Peshkoff wrote:
On 02/28/14 21:01, Dimitry Sibiryakov wrote:
Attached patch gives to isc_dsql_fetch(), isc_dsql_execute2() and
isc_dsql_exec_immed2() ability to work with wide result set.
At the first look this should
03.03.2014 12:54, Alex Peshkoff wrote:
If we apply that change SQLDA-oriented functions can work with 64K
messages but BLR-oriented statements and requests - can not.
Fortunatelly, I don't know anybody who use them. They are not documented
from the
middle of past century and I wonder why
non-priviledged user can block creation of new tables by select ... from
rdb$database FOR UPDATE WITH LOCK
--
Key: CORE-4357
URL:
On 03/03/14 16:00, Dimitry Sibiryakov wrote:
03.03.2014 12:54, Alex Peshkoff wrote:
If we apply that change SQLDA-oriented functions can work with 64K
messages but BLR-oriented statements and requests - can not.
Fortunatelly, I don't know anybody who use them.
Anyone who is using gpre.
03.03.2014 17:57, Alex Peshkoff wrote:
Anyone who is using gpre.
Which is exactly one man.
But I suggest not to waste time and wait for a week (or 2 - taking into
an account AGM).
No problem with waitin for me, though I'd prefer to follow principe fix
what you can
and leave the rest
03.03.2014 20:57, Alex Peshkoff wrote:
If we apply that change SQLDA-oriented functions can work with 64K
messages but BLR-oriented statements and requests - can not.
Fortunatelly, I don't know anybody who use them.
Anyone who is using gpre.
If we speak about indirect usage, could gbak
03.03.2014 18:50, Dmitry Yemanov wrote:
If we speak about indirect usage, could gbak as well.
Its result set cannot be wider than record, which is still limited to 64k,
so no
problem here.
--
WBR, SD.
--
03.03.2014 21:54, Dimitry Sibiryakov wrote:
Its result set cannot be wider than record, which is still limited to 64k, so
no
problem here.
We can allow records longer than 64K in a second. The only reason why it
was not done yet is the old API problem in gbak. I hope Alex will
rewrite the
-Original Message-
From: Alex Peshkoff [mailto:peshk...@mail.ru]
Sent: Lunes, 03 de Marzo de 2014 5:28
On 03/02/14 11:32, Claudio Valderrama C. wrote:
Hello, I have two doubts concerning gbak in v3:
1.- Should rdb$linger be stored in the backup?
I think yes
Done, not
16 matches
Mail list logo
