I read that CONSISTENCY imposes table locking even for read operations
which means that I will continue using CONCURRENCY mode. Additionally, I
will not run both update processes at the same time to avoid the problem I
have been having.
On Sat, Dec 19, 2015 at 11:01 PM, Caroline Beltran <
carolin
Alan, I think you are right. I backed up then restored my database. Next
I installed SuperServer and everything was going very well. Here are my
stats:
Database header page information:
Flags 0
Checksum12345
Generation 22516
I can reproduce this 'stalling' behavior. At the moment, the application is
importing records without delay. CPU consumption remains very low.
To stall FB, I will now run a query that will scan several thousands of records
that have just been INSERTed and UPDATEd. Before I run this query, her
I can reproduce this 'stalling' behavior. At the moment, the application
is importing records without delay. CPU consumption remains very low.
To stall FB, I will now run a query that will scan several thousands of
records that have just been INSERTed and UPDATEd. Before I run this query,
here
Here are some more details. I used GBAK to backup and then restored the
database. Here are the gstat details:
Database header page information:
Flags 0
Checksum12345
Generation 30
Page size 4096
I have happily used Firebird 2.5 for a web application that run 24x7 for at
least 2 years. The sweep interval is set to the default 20,000 and it
works very well. There is at least 10 inserts per minute but not much more
than that. I would guess that there are at least 20 reads per second and
I'
Den 19.12.2015 20:38, skrev 'Daniel Miller' dmil...@amfes.com
[firebird-support]:
> With correction for one or two typos - those both worked, thank you!
> Had to read, and read, and read - to try to understand HOW these work.
> Which was exactly what I was hoping for - to better understand usage o
As an amateur - I'd suggest using an indexed field in the where clause,
and choosing an invalid value that is less than the 1st real entry.
--
Daniel
-- Original Message --
From: "josef.gschwendt...@quattro-soft.de [firebird-support]"
To: firebird-support@yahoogroups.com
Sent: 12/19
With correction for one or two typos - those both worked, thank you!
Had to read, and read, and read - to try to understand HOW these work.
Which was exactly what I was hoping for - to better understand usage of
Firebird SQL.
Looking at the query plans, it appears Alternative 2 - which uses t
Hi,
the following select fetches all records of the table (FB 2.5.4) and obviously
brings no resultset.
select * from Mytable where 1=0
Is there a trick to force Firebird not to scan all records?
We sometimes use such a statement (in for select loops) to get different
datasets and process
Here's two alternatives for you, they should give the same result
(though provide different options for modifications, see the comments
inside the SQL), pick the one you prefer. Both differ from your SQL in
that rows are also returned when there are no routes, whereas your SQL
would require at
11 matches
Mail list logo
