10.02.2018 22:33, Aldo Caruso wrote:
>
> A strange behavior is seen in the combination not null and no default
> value. It is returned as a 0 for selects but treated as a NULL when
> comparing.
In fact, the engine returns NULL. But query prepare describes the output
descriptor as NOT NULL. Some
> Your last advice concerns me a bit. Is it also valid for
> changing stored procedures or triggers ?
As an abiding principle - yes. But, for SPs and triggers, the effect
varies according to a few factors. The BLR for these modules is
cached on first use. Changes conducted whilst the
Hello Helen,
I saw your answer after I had replied to Dimitry. It is clear that
there is no automatic filling and I'm responsible to fill fields with
not null constraint.
Your last advice concerns me a bit. Is it also valid for changing
stored procedures or triggers ?
Should I have
Thanks for your answer.
I made some tests and found some strange exceptions to the rules you
described.
Consider the following DDL sentences, which create four fields with the
for possible combinations for default value and not null constraint:
alter table table1 add test1 integer;
alter
Hello Aldo,
> My questions are the following:
> 1) Is the intended effect to fill behind the scenes a newly created
> field with its default value when there is a not null constraint ?
No. Only inserts subsequent to the commit of the DDL for the new
field will use the default in the case
10.02.2018 16:32, Aldo Caruso aldo.car...@argencasas.com [firebird-support]
wrote:
> I discovered that when a field is added to a table with a NOT NULL
> constraint and a default value, it is automatically filled with that
> default value.
No, it isn't. It would be too slow.
Default value
Hi,
you store in your persistent table login (user_name) it is presistent
information.
You join your persistent table which should contain login name and you join
your persistent table with mon$attachment an you know who is currently logged
in.
once again sample
CREATE TABLE MY_USERS
Hello,
I discovered that when a field is added to a table with a NOT NULL
constraint and a default value, it is automatically filled with that
default value. Example:
alter table table1 add field1 integer default 1 not null;
commit;
select distinct field1 from table1;
FIELD1
Hi,
I have a table of users, but I wouldn't store in persistent table a
volatile information (if it was possible).
The link between a connection id and user id isn't a persistent information
(like connections,transaction ecc...)
2018-02-08 6:19 GMT+01:00 liviuslivius liviusliv...@poczta.onet.pl
