Hi Karol,
what Windows 2008 memory problem are You refering to that needs 2.5.3?
Thanks
Zsazsi
2014-05-13 7:23 GMT+02:00 'liviusliv...@poczta.onet.pl'
liviusliv...@poczta.onet.pl [firebird-support]
firebird-support@yahoogroups.com:
Hi,
Your database is not big but your settings are
Hi,
Write in google firebird and windows 2008 cache problem and you will see
Regards,
Karol Bieniaszewski
- Reply message -
Od: Zsazsi m-zs...@freemail.hu [firebird-support]
firebird-support@yahoogroups.com
Do: firebird-support@yahoogroups.com
Temat: [firebird-support] Cache
By the way, Bhavbhuti,
CAST(COALESCE(tPB.dBillDt, '') AS TIMESTAMP) AS tDocDt
will fail if tPB.dBillDt is null since '' cannot be converted to a timestamp
(it is neither a timestamp nor null).
Set
Thanks Svein. Would you suggest I double COALESCE it? I think it will be an
overkill and I might end up with an ANSI datetime again.
Or should I not COALESCE it at all? I wanted a blank date time in case of a
NULL for tBillDt and if there is a date in tBillDt I need
it for date calculation
Hi Karol,
I can see nothing related, The only problem that shows up was fixed in
2.5.2 already.
http://tracker.firebirdsql.org/browse/CORE-3791
Do You know something more specific?
Regards
Zsazsi
2014-05-13 8:56 GMT+02:00 'liviusliv...@poczta.onet.pl'
liviusliv...@poczta.onet.pl
Svein, Bhavbhuti has a background as a Visual FoxPro developer and in that
language exist empty dates.
Probably is the reason why he had casted an empty string as a timestamp.
The same thing had happened to me when I was learning SQL.
Greetings.
Walter.
On Tue, May 13, 2014 at 4:02 AM,
Set,
There is a large gap because I turned off auto sweeping. I disabled it
because when it was sweeping, it was killing performance even more.
Previous to the 2.5.2 update, it was also using all the memory and causing
the server to swap every time it did a sweep (20,000 transactions). Right
now,
Large gap is not caused by lack of auto sweep. It is bad system design.
As you is not the system programmer, you can shut down all connections to the
database during lunch time, then you can let users enter in your system again.
After shutting down, run a manual sweep (gfix –sweep). If you see
Karol,
I have set my page buffers at 130,000 because I cannot go any higher.
Still, the firebird process won't use more than 600MB of memory and I
assume this is due to 32bit. Would upgrading to 64bit allow me to use more
page buffers? Right now, I have my page buffers on that specific database
That is exactly what I'm doing right now. Its the only way to keep them
going. I shut them down at lunch, run a sweep, then when they get back in,
things are much faster.
-Josh
On Tue, May 13, 2014 at 8:35 AM, 'Fabiano - Desenvolvimento SCI'
fabi...@sci10.com.br [firebird-support]
Josh, you have a system error.
No Firebird configuration can deal with that scenario.
The only solution is tell this to your system programmer. He will take a look
and fix your system. The gap between transactions will be reduced and your
system will run fast everything.
Probably it will by
Your problem is:
PLAN JOIN (SP NATURAL, A INDEX (ADVOCATE_))
Wish means a full table scan on SUPPROG. It is strange, because you have the
index
USV_SUPPROG_ADVOCATE_CODE ON field ADVOCATE_CODE
Try this:
select * from
(
select a.User_ID
from Advocate
where a.USER_ID=37
) as
Maybe.
Try update all index statistics. MAYBE it helps.
In last case MAYBE a backup/restore can help too… (or drop and recreate those
indexes)
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
Enviada em: terça-feira, 13 de maio de 2014 17:15
Para:
Em 13/5/2014 17:14, Kevin Donn kd...@msedd.com [firebird-support] escreveu:
Try this:
select * from
(
select a.User_ID
from Advocate
where a.USER_ID=37
) as FILTER1, supprog sp
Where sp.ADVOCATE_CODE=FILTER1.Advocate_Code
This doesn't quite
This doesn't quite execute. I cleaned it up to this:
select * from (
select a.User_ID, a.ADVOCATE_CODE
from Advocate a
where a.USER_ID=37
) as FILTER1,supprog sp
Where sp.ADVOCATE_CODE=FILTER1.Advocate_Code
It gets the same plan: PLAN JOIN (SP NATURAL, FILTER1 A INDEX
Set,
There is a large gap because I turned off auto sweeping. I disabled it because
when it was sweeping, it was killing performance even more. Previous to the
2.5.2 update, it was also using all the memory and causing the server to swap
every time it did a sweep (20,000 transactions).
Are the statistcs up to date ?
Statistics are not something I understand well. I have run SET STATISTICS
INDEX USV_SUPPROG_OWNER_USER_ID on all indexes of the two tables. I'm
guessing that brings them up to date, correct? No change in the query.
The two tables you mentioned has the same
On Tue, May 13, 2014 at 4:33 PM, 'Leyne, Sean'
s...@broadviewsoftware.com[firebird-support]
firebird-support@yahoogroups.com wrote:
Questions:
1- What indexes do you have defined on a.User_ID?
CREATE INDEX IDX_ADVOCATE1 ON ADVOCATE (USER_ID);
2- What is the selectivity (aka uniqueness)
Database header page information:
Flags 0
Checksum12345
Generation 715138
Page size 4096
ODS version 11.2
Oldest transaction 676463
Oldest active
Hi Kevin,
let me first answer one of your particular questions:
I don't really
understand statistics but USV_SUPPROG_ADVOCATE_CODE
has 0.029412 and USV_SCHLHIST_ADVOCATE_CODE
has 0.000422.
with the first index, you've about 3% of records with the same value in
index (these are going to be
s...@broadviewsoftware.com [firebird-support] firebird-
supp...@yahoogroups.com wrote:
Questions:
What about the SQL I recommended??
Sean
Oops:
If you know, that the stored procedure returns view records, connect ...
I meant: few records
--
Mit freundlichen Grüßen,
Thomas Beckmann
Diplom-Informatiker
Wielandstraße 14c • 23558 Lübeck
Tel +49 (22 25) 91 34 - 545 • Fax +49 (22 25) 91 34 - 604
Mail thomas.beckm...@assfinet.de
25 matches
Mail list logo
