, Robbert-Jan wrote:
I’m trying to retrieve the explain plan of the last prepared query,
using the mon$explained_plan field, introduced in FB3 beta.
I used:
SELECT mon$explained_plan FROM mon$statements WHERE mon$transaction_id =
CURRENT_TRANSACTION
Wrong. You should use WHERE mon$attachment_id
bericht-
From: Dmitry Yemanov
Sent: Wednesday, March 18, 2015 8:53 PM
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] Retrieving plan using new mon$explained_plan
field (FB3 beta )
18.03.2015 22:37, Robbert-Jan wrote:
If I execute this scenario (using FlameRobin
Hi,
I’m trying to retrieve the explain plan of the last prepared query, using the
mon$explained_plan field, introduced in FB3 beta.
I used:
SELECT mon$explained_plan FROM mon$statements WHERE mon$transaction_id =
CURRENT_TRANSACTION
This seems to give me however the plan of the first prepared
Hi,
I’ve tested the “unofficial” FB 3.0 beta-1 release (after installing it with
the “unofficial” installer) for a couple of weeks now.
I am now at a point, that I start missing the release notes, just to get a
better understanding of the new features and for designing my test cases
efficiently
)
Sent: Monday, October 27, 2014 5:19 PM
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] Beta 1: recreating package
failswithsignaturemismatch error
Hello Robbert-Jan,
Private functions not exposed to the outside is one of the things you can
do with packages.
Mind
Hi,
While restoring a database with FB 3.0 beta 1 (backed-up with FB3 alpha 2), I
get this error:
action cancelled by trigger (3) to preserve data integrity
object has non-SQL security class defined
Exiting before completion due to errors
SQL state: 27000
SQL code: -901
FB version:
class defined
27.10.2014 12:30, Robbert-Jan wrote:
While restoring a database with FB 3.0 beta 1 (backed-up with FB3 alpha
2), I get this error:
action cancelled by trigger (3) to preserve data integrity
object has non-SQL security class defined
Can you provide us with this backup?
Dmitry
Subject: Re: [Firebird-devel] Firebird 3.0 beta database recover problem:
object has non-SQL security class defined
Am 27.10.2014 um 10:45 schrieb Dmitry Yemanov:
27.10.2014 12:30, Robbert-Jan wrote:
While restoring a database with FB 3.0 beta 1 (backed-up with FB3 alpha
2), I get this error
Hi Martijn,
Maybe it is too obvious, but it looks like your body has four routines and your
header only three (CHECK_INVOICE_EXISTS is missing), hence the signutare
mismatch.
Kind regards,
Robert
From: Martijn Tonies (Upscene Productions)
Sent: Monday, October 27, 2014 12:54 PM
To:
Already reported by DOC-92.
-Oorspronkelijk bericht-
From: Mark Rotteveel
Sent: Tuesday, October 21, 2014 10:14 PM
To: firebird-devel@lists.sourceforge.net
Subject: [Firebird-devel] Bug release notes 3.0 Alpha 2
Helen,
In the release notes for 3.0 Alpha 2 I noticed the following bug
Hi,
I’m trying to install Firebird 3 Beta-1 on Windows XP
(Firebird-3.0.0.31369_0_Win32.exe).
I get the following error from gsec.exe during installation:
An error occurred while attempting to add the user.
Incompatible data type
I *guess* this occurs when the installation process tries to
I've deleted all of firebird_3_0 directory and installed beta-1 again.
Installation of beta-1 is finishing without problems now!
Thanks, Robert
-Original mail -
On 10/22/14 17:07, Robbert-Jan wrote:
Hi,
I’m trying to install Firebird 3 Beta-1 on Windows XP
(Firebird
Probably no beta release this week with all those drunken developers...
From: Martijn Tonies (Upscene Productions)
Sent: Monday, October 20, 2014 7:24 PM
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] Prague
Raising the bar, Mark?
--
Martijn
Hi,
People who want to hide the source code can write an external
procedure/function (engine udr) and only distribute the dll file.
Kind regards,
Robert
-Oorspronkelijk bericht-
From: Carlos H. Cantu
Sent: Thursday, August 28, 2014 10:30 PM
To: For discussion among Firebird Developers
Hi,
I understand the dilemma. I think it is inherent in having separate
statements for defining header (interface) and body (implementation). This
was probably done to be compatible with other sql databases??
But anyway, it is too late now to change this concept;)
If a new field with the old
Hi,
Already reported by DOC-92 (http://tracker.firebirdsql.org/browse/DOC-92)
for alpha1.
I guess changing the documentation is the easiest way around, otherwise
don't forget to change rdb$types too.
Kind regards,
Robert.
-Oorspronkelijk bericht-
From: Thomas Kellerer
Sent: Saturday,
On 16/12/2013 05:08, Alex Peshkoff wrote:
I prefer to:
alter user x password 'y' set a = 'a', b = 'b';
Me too.
Adriano
And me too.
Will the new name-value pairs also be retrievable from sec$users? And if
yes, how ? Text blob with all pairs?
Kind regards,
Robert
- NL
Hi,
Domain defaults seem not to be applied for SP ending parameters, see case
below.
Is this as designed, or a bug, or a request? I just want to be sure before I
issue a Jira tracker.
CREATE DOMAIN MyDomain1 AS INTEGER DEFAULT 1
CREATE PROCEDURE MyProcedure1 (Var1 MyDomain1) RETURNS (Var2
Hi,
I see that the COMMENT ON syntax has been changed in FB 3.0
In stead of only
COMMENT ON PARAMETER ProcName.ParamName
now also
COMMENT ON PROCEDURE PARAMETER ProcName.ParamName
COMMENT ON FUNCTION PARAMETER FuncName.ArgumentName
is allowed.
I think this was introduced because of
To: firebird-devel@lists.sourceforge.net
Subject: Use of system tables for identity columns
Regarding the new identity column feature in Firebird 3 alpha:
The new fields rdb$generator_name and rdb$identity_type are now defined in
rdb$relation_fields.
I think it would be more consistent if
Hi,
I think current behaviour of ALTER DOMAIN regarding CHARACTER SET is
correct.
CHARACTER SET is part of the datatype clause. So omitting CHARACTER SET
means the default character set has te bo taken.
If you want to keep the current (non-default) character set, you have to
repeat it in the
Hi,
I like your opinion on the following sql improvement before I submit a JIRA
request:
For domains it is possible to alter multiple changes in one statement.
For example:
CREATE DOMAIN MyDomain INTEGER DEFAULT 0 NOT NULL
ALTER DOMAIN MyDomain TO MyDomain2 TYPE BIGINT SET DEFAULT 1 NULL /*
Hi,
I like to propose a more consistent syntax for computed columns and identity
columns:
Computed columns are now defined in DDL as
ColumnName [DataType] GENERATED ALWAYS AS (Expression)
while identity columns (as of FB 3.0 CORE-1385) are defined as:
ColumnName {DataType|DomainName}
Thanks Adriano, Sean and Mark,
You are right. I do not no what I was thinking but specifying BY DEFAULT for
computed columns makes indeed no sense.
Kind regard,
Robert
On 30/08/2013 11:28, Robbert-Jan wrote:
Hi,
I like to propose a more consistent syntax for computed columns and
identity
24 matches
Mail list logo
