Hello everybody
When I run GSTAT with the switch -data it shows me numbers after "data
pages" and "data page slots".
Usually these numbers are the same, but ... what happen when they are
different?
I understood that the difference between them means the count of pages
without any relevant data.
Hi,
this is only for info if someone is worry about FB3 stability.
I run very big deletion statement in concurrent env - i clear 90% of old
historical data from database
and FB run without any problem this big command :)
below are stats:
Executing statement...
Statement executed (elapsed tim
Hi Martin,
Thank you for yor concern. I don't explore the source code of firebird, but I
guess your opinion is correct.
Regards,Tjioe Hian Pin
On Friday, 9 December 2016, 21:13, "Köditz, Martin martin.koed...@it-syn.de
[firebird-support]" wrote:
Hi, I think the answer is simpl
Hmm. I restarted everything and now it seems to be returning a result. I
haven't managed to recreate the issue so, I'll leave this for now.
Many thanks for your input
The link is not double precision columns, the link is on the VarChar columns.
Rows are returned and the first 2 columns show the TableA.Amount and and the
TableB.Value.
The issue is the 3rd column (TableA.Amount / TableB.Value) always returns NULL.
---In firebird-support@yahoogroups.com,
12.12.2016 12:05, russ...@smxi.com [firebird-support] wrote:
> The query does return rows and shows the AMOUNT from Table A and the VALUE
> from Table B.
> All of which have values. It is the calculated field (A.AMOUNT / B.VALUE)
> that returns null.
Can you copy-paste some results from *isq
The links aren't on the double precision fields, they are on the VarChar(12)
link fields.
The query does return rows and shows the AMOUNT from Table A and the VALUE
from Table B. All of which have values. It is the calculated field (A.AMOUNT /
B.VALUE) that returns null.
If the problem is that it doesn't return any rows (and not that the rows
contain null values), then I would expect the reason to be that DOUBLE
PRECISION is a floating point and not fixed point datatype. Floating point
datatypes never contain exact values, e.g. what you think is 15.3 may be
stored
There are no NULL values in either of the columns (that was my first thought).
The table structure is
TABLEA
URN: VARCHAR(12)
LINKURN: VARCHAR(12) [Links to TABLEB.ID]
AMOUNT: DOUBLE PRECISION
TABLEB
URN: VARCHAR(12)
VALUE: DOUBLE PRECISION
so the query is
SELECT A.AMOUNT, B.VALU
