>So, what I wanted to avoid is for the query optimizer to join all tables first
>and only
>then apply the != 'UNASSIGNED' filter. Instead, I wanted the optimizer to
>apply the filter
>to the PROJECT table first, then join (and find 10 matching rows) and only
>after that do
>the aggregation. An
--- In firebird-support@yahoogroups.com, Mark Rotteveel wrote:
>
> On Mon, 20 Feb 2012 09:51:19 -, "venussoftop"
> wrote:
> > Hi all
> >
> > I have tables that can allow me to filter data like this:
> > SELECT a.*
> >FROM tablea a
> >WHERE a.iTableBLinkID NOT IN (SELECT b.iPKID FRO
--- In firebird-support@yahoogroups.com, Mark Rotteveel wrote:
>
> On Mon, 20 Feb 2012 09:51:19 -, "venussoftop"
> wrote:
> > Hi all
> >
> > I have tables that can allow me to filter data like this:
> > SELECT a.*
> >FROM tablea a
> >WHERE a.iTableBLinkID NOT IN (SELECT b.iPKID FRO
it's seam that i made a mistake in the way i want to retrieve the stat of the
current Statement
I need to do
MON$STATEMENTS.MON$Statement_ID= ...
instead of
MON$STATEMENTS.MON$ATTACHMENT_ID=CURRENT_CONNECTION
the problem : how to retrieve the statement ID ?
i create the statement via the API :
What about :
SELECT
PROJECT."PRIMARY_PROJECT_CODE" AS COL0,
COUNT(PHYSICAL_COPY."ID") AS COL1
FROM
PROJECT
LEFT JOIN PROJECT_CODE_DESCRIPTOR ON PROJECT_CODE_DESCRIPTOR."PROJECT_ID"
= PROJECT."ID"
JOIN COPY_CLASSIFICATION ON COPY_CLASSIFICATION."CLASSIFICATION_CODE" =
PROJECT_CODE_DESCR
Hi Arno!
Is Firebird intelligent enough to use an index for
PROJECT."ASSIGNMENT_STATUS" != 'UNASSIGNED'
when over 99% of the data contains 'UNASSIGNED'? I thought we had to wait for
Firebird 3 to see histograms and that 'not equal' would not be able to
efficiently use an index before that?
Ea
> I have a question on backup/restore.
>
> Think of a firebird classic on a linux box.
>
> -Do a backup with existing attachments
> -After backup, Rename the old gdb file to something else
> -Restore the backup file with the original gdb name.
You have to kill all connected clients before startin
Hi, I get your point.
But I wonder what can happen when we don't kill the existing clients before
restoring with the same database file name.
Actually I had a bad exprience on this :)
-One client remained active after a restore operation and continued to run on
the newly restored database. (I
Actually, active users stay connected to old renamed database.
It can happen only on linux, never on Windows.
Regards
Bogdan
>Hi, I get your point.
>But I wonder what can happen when we don't kill the existing clients before
restoring with the same database file name.
>Actually I had a ba
Set and Arno,
Thank you both of you for your solutions! Arno's solution required swapping
the order of PROJECT and PROJECT_CODE_DESCRIPTOR tables in the join and
use LEFT JOIN instead of INNER JOIN to join them. This is so simple and the
results are amazing.
PLAN SORT (JOIN (JOIN (JOIN (PROJECT
10 matches
Mail list logo
