[Firebird-docs] LangRef 2.5beta1 - a few suggestions

2016-03-10 Thread Aage Johansen
I may be way too late, or others may have noted 
these already.  This is a few suggestions that I collected in February:

==
Document version: 0.901



P.13Integer Data Types
BIGINT is defined as 64-bit integer, INTEGER is 
defined as 4-byte integer.  SMALLINT reveals 
nothing about bits or bytes.  Not very 
consistent, but maybe this is all according to SQL rules?
The  create table example for INTEGER contains 
“CONSTRAINT INTEG_60” ­ is this a good example?


P.17Data Types for Dates and Times
There are examples of the extract function (p.18) 
for TIME, but none for DATE.  Extract functions 
for DATE are only mentioned in passing under TIMESTAMP (p.18).


P.22Table 3.5. Maximum Index Lengths by Page Size and Character Size
The text above the column header “Maximum length 
of an indexed string for a character set, 
bytes/character” should just be “Bytes/character” 
(for the numbers 1 thru 6 in the column sub-headers).



P.30Table 3.8. Literals with Predefined Values of Date and Time
A small glitch with the lines in the lower right 
of the table (or a pdf rendering problem?).


P.31Shorthand Casts for Date and Time Data Types
TIMESTAMP has been split over two lines as TIMES-TAMP.


P.32Implicit Data Type Conversion
<<
Implicit data conversion is not possible in 
Dialect 3 ­ the CAST function is almost always 
required to avoid data type clashes.
In Dialect 1, in many expressions, one type is 
implicitly cast to another without the need to 
use the CAST function. For instance, the 
following clause in a Dialect 1 SELECT statement is valid:
WHERE DOC_DATE < '31.08.2014'
and the string type will be cast to the date type implicitly.
 >>
Valid in dialect 3 (as well as in dialect 1), I think.


==
I had a few more, but realized they were the product of my confusion :-/


-- 
Aage J. 


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs


[Firebird-docs] LangRef 2.5beta1 - a few more suggestions /4

2016-04-06 Thread Aage Johansen


==

p.87
Maybe a few words on the naming of "unnamed" constraints.
create table TEST (
   ID  integer  not null  primary key
)
The user might like to know that 2 constraints are created, called 
INTEG_n (f.ex. INTEG_157 (for "not null") and INTEG_158 (for "primary 
key")).  And the (unique) index will be named rdb$primaryN (f.ex. 
rdb$primary66).



p.104
Index Direction:
Explain why the user might want to have the (non-default) descending index.
Maybe that is more appropriate in an "User's Guide"?



p.107 (Active option: How is it useful?)
from:
... on the indexes of a large table in a database that is 
infrequently restored.
to:
... on the indexes of a large table in a database that is frequenty 
updated and infrequently restored.
(Maybe not really necessary?)

( I didn't know that ACTIVE will rebuild an active index - good to know! )

Any good advice on using "alter index ..." and "set statistics ..." 
when the table is in use?
Is it ok, impossible, adviced against, or an absolute no-no?



p.109
Index Selectivity

Index statistics in Firebird are not automatically recalculated, 
either after a lot of data has been modified or under any other conditions.
->
Index statistics in Firebird are not automatically recalculated, not 
after data has been modified or under any other conditions.
(I don't like this sentence, but couldn't find a better one)

It may be necessary to recalculate the selectivity of an index after 
inserting, updating or deleting a large number of records in the 
table, because the selectivity tends to become outdated.
->
It may be advantageous to recalculate ...



p.111
Updateable Views

the SELECT statement contains no ORDER BY or GROUP BY or GROUP BY clause
->
the SELECT statement contains no ORDER BY or GROUP BY clause





Another completely different thing (on comparison operators):
What about varchars with trailing blanks - how do these compare with 
chars and varchar (without trailing blanks)?
Maybe this is not stuff for a LangRef, but for "User's Guide" or SQL tutorial?
I have a feeling that this either has been mentioned already or it is 
covered already in the LangRef - I just couldn't find it now.

==

-- 
Aage J.


--
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs


[Firebird-docs] LangRef 2.5beta1 - a few more suggestions /5

2016-04-10 Thread Aage Johansen

I'll have mostly non-Firebird things on my mind the next week, so I'm 
just unloading my latest comments now!

==
p.117
Add a sentence to make it clear when the trigger is fired:
For mutation events, does the trigger fire at commit or at individual 
insert/update/delete.
For two-phase-commit, it is described at p.122 (good!).

p.119:
"Declarations and embedded statements are terminated with semi-colons (;)."

For statements with a begin...end block, no semi-colon is used.


Simple "if":
   BEGIN
 IF (NEW.cust_no IS NULL) THEN
   NEW.cust_no = GEN_ID(cust_no_gen, 1);
   END

But, with a block of statements:
   BEGIN
 IF (NEW.cust_no IS NULL) THEN
 BEGIN
   NEW.cust_no = GEN_ID(cust_no_gen, 1);
 END
   END

p.248 reveals that
"The BEGIN and END statements have no line terminators."
This explains it, but:
a)
This is a trap for new users - please make a note around p.119 (about 
semi-colons).
b)
"line terminators"?  "statement terminator" seems better.

And "embedded statements" - are these just ordinary statements in the trigger?



p.124
ALTER TRIGGER set_cust_no INACTIVE;

Does this have immediate effect, even without a commit?
If a user inactivates a trigger, does something and then activates 
the trigger - what is
the effect for users (in the inactive periode)?  And, is it really 
inactive (without a commit)?
I believe there has been some confused/confusing discussions on the 
support list in the past on whether
a user can have a trigger de-activated just for himself.  (He cannot, IIRC)

==

-- 
Aage J.


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs


[Firebird-docs] LangRef 2.5beta1 - a few suggestions /2b

2016-03-20 Thread Aage Johansen

A few more:



  p.53   (top)
[ ] ( ) | ^ - + * % _ ? {


No "}" (terminating brace) ?


[:ALPHA:]: Latin letters a..z and A..z.
Should be:  a..z and A..Z ?





p.57   Existential Predicates
... Existential predicates are so called because they use various 
methods to test the existence of the value on the left side of the 
predicate in the output results of subqueries on the right.

Using the first example:
   SELECT *
   FROM employee
   WHERE EXISTS(SELECT *
FROM employee_project ep
WHERE ep.emp_no = employee.emp_no)

What is the "value on the left side of the predicate" and what is 
"output result of subqueries on the right"?
It is not intuitive to me.

It seems to be better explained in the next paragraph, but the end is 
not very clear:
... tests the fact of the existence of any number of matching rows 
that is greater than none.

Would something like
... tests the existence of at least one matching row.
be simpler and clearer?



-- 
Aage J.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs