Hi,

|how to cast a timestamp field to Integer ? i can eventually truncate the
time of the TimeStamp.

you can cast (timestamp_field as date) and than you can subtract from some
"arbitrary" base date -- like the "zero" date that, *AFAIR* is 12/30/1899
but you need to confirm that.


Regards,
Anderson

You can't cast directly, however you can do the following:

   select cast(current_timestamp - cast('12/30/1899' as timestamp) as
integer)
   from rdb$database

Subtracting 12/30/1899 will subtract 0 and not alter the date/time you
already have, however it will force the result to be returned as
numeric(18,9) which can then be cast as int.


[Non-text portions of this message have been removed]

The only thing that I notice probably could be optimized, is that I doubt it
will ever be useful to use an index for validfrom (due to your description). So,
change to

SELECT d.datakey, MAX(h.histkey) histkey
FROM data d
LEFT JOIN history h ON h.code=d.code AND h.deleted=0 AND
h.validfrom+0<='now' AND h.validto+0>'now'
WHERE COALESCE(d.code,0)<>COALESCE(h.code,0)
GROUP BY d.datakey

Other than that, well, if you run an identical query (note the word identical,
it is not identical if it e.g. uses different parameters) twice on the same
database with vastly different execution time, then I'd expect either cache
(quicker on second run), different plan or something external to the query (e.g.
sweep) to be the reason.

One thing I noted on Firebird 1.5 not all too long ago, was that indexed fields
with lots of nulls made one of my queries very slow. However, that was not slow
sometimes, it was always slow.

HTH,
Set

-----Original Message-----
From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com]
On Behalf Of PenWin
Sent: 25. november 2009 13:19
To: Firebird Support
Subject: [firebird-support] Sudden increase in execution times

Hi!

Under Firebird 1.5.5 running under Windows Vista I have a query which
exhibits great variance in execution times - sometimes it takes 1.5
seconds, sometimes much longer (I have seen more than 9 minutes). The
query tries to find records in the data table which are linked to
obsolete records in the history table. Something like:

Data ( DATAKEY integer, DATA1, DATA2, ..., CODE integer )
History ( HISTKEY integer, HISTDATA1, HISTDATA2, ..., CODE integer,
VALIDFROM timestamp, VALIDTO timestamp, DELETED integer )

The query:

SELECT d.datakey, MAX(h.histkey) histkey
FROM data d
LEFT JOIN history h ON h.code=d.code AND h.deleted=0 AND
h.validfrom<='now' AND h.validto>'now'
WHERE COALESCE(d.code,0)<>COALESCE(h.code,0)
GROUP BY d.datakey

Alternative version, with almost the same behavior (I do the COALESCEd
compare in application rather than the query itself):

SELECT d.datakey, (SELECT MAX(h.histkey) FROM history h WHERE
h.code=d.code AND h.deleted=0 AND h.validfrom<='now' AND
h.validto>'now') histkey
FROM data d

"Data" has some 70000 rows. "History" has about 10 rows for each "Data"
row, with indexes on code, on validfrom and on validto (three distinct
indexes). The execution plan (for the former query) looks fine to me:

PLAN SORT (JOIN (Data NATURAL,History INDEX (codeidx,validfromidx)))

What could be the problem?


Thanks, Pepak

Hi PenWin,

Just to rule out:

I once noticed the same behaviour (sudden slowness of a query), but it
turned out to be someone on the network was busy copying allmost an
entire harddisk to the server... IOW, a network congestion problem and a
very busy server....

regards,
John





PenWin wrote:
> Hi!
>
> Under Firebird 1.5.5 running under Windows Vista I have a query which
> exhibits great variance in execution times - sometimes it takes 1.5
> seconds, sometimes much longer (I have seen more than 9 minutes). The
> query tries to find records in the data table which are linked to
> obsolete records in the history table. Something like:
>
> Data ( DATAKEY integer, DATA1, DATA2, ..., CODE integer )
> History ( HISTKEY integer, HISTDATA1, HISTDATA2, ..., CODE integer,
> VALIDFROM timestamp, VALIDTO timestamp, DELETED integer )
>
> The query:
>
> SELECT d.datakey, MAX(h.histkey) histkey
> FROM data d
> LEFT JOIN history h ON h.code=d.code AND h.deleted=0 AND
> h.validfrom<='now' AND h.validto>'now'
> WHERE COALESCE(d.code,0)<>COALESCE(h.code,0)
> GROUP BY d.datakey
>
> Alternative version, with almost the same behavior (I do the COALESCEd
> compare in application rather than the query itself):
>
> SELECT d.datakey, (SELECT MAX(h.histkey) FROM history h WHERE
> h.code=d.code AND h.deleted=0 AND h.validfrom<='now' AND
> h.validto>'now') histkey
> FROM data d
>
> "Data" has some 70000 rows. "History" has about 10 rows for each "Data"
> row, with indexes on code, on validfrom and on validto (three distinct
> indexes). The execution plan (for the former query) looks fine to me:
>
> PLAN SORT (JOIN (Data NATURAL,History INDEX (codeidx,validfromidx)))
>
> What could be the problem?
>
>
> Thanks, Pepak
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu.  Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>
>


--
John vd Waeter
www.jvdw.nl
www.gps-carpool.net
www.shotinthedark.nl
www.pdaforms.nl
www.dbapocket.nl

john@...

PenWin wrote:
>>>
>> If you are deleting in one of the tables regularly, then you might
>> suffer from garbage collection at SELECT time, depending on the
>> architecture (SuperServer, ClassicServer) you use.
>>
> There are no deletes on either of the tables. If hiding from the user is
> required, it is done by setting history.deleted to 1.
>

Ah.  That's almost the same cost as a deletion - the old version of the
history record has to be garbage collected.  If there's an index on the
deleted field in history, the index entry must also be removed.  Since
there are likely to be LOTS of entries in that index with the same
the index deletion will be expensive ... less so in 2.0x than 1.5x.

Good luck,

Ann

>
> You can't cast directly, however you can do the following:
>
>   select cast(current_timestamp - cast('12/30/1899' as timestamp) as
> integer)
>   from rdb$database
>
> Subtracting 12/30/1899 will subtract 0 and not alter the date/time you
> already have, however it will force the result to be returned as
> numeric(18,9) which can then be cast as int.
>

But surely this will give the date only (when you cast).
What does the op want? the time? or the date?
Alan

no, it's work perfectly, and return me an integer :)

--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...> wrote:
>
> >
> > You can't cast directly, however you can do the following:
> >
> >   select cast(current_timestamp - cast('12/30/1899' as timestamp) as
> > integer)
> >   from rdb$database
> >
> > Subtracting 12/30/1899 will subtract 0 and not alter the date/time you
> > already have, however it will force the result to be returned as
> > numeric(18,9) which can then be cast as int.
> >
>
> But surely this will give the date only (when you cast).
> What does the op want? the time? or the date?
> Alan
>

no, i just install FB 2.1.3 and nothing change ! again the server crash and
closing the client not shunt down the fb_inet_server.exe :(
no other choice than restart the server... this become a serious problem for me
....

in the fb log i have this :

AKSERVER Wed Nov 25 20:36:59 2009
	 INET/inet_error: read errno = 10054


AKSERVER Wed Nov 25 20:36:59 2009
	 INET/inet_error: read errno = 10054


AKSERVER Wed Nov 25 20:36:59 2009
	 INET/inet_error: read errno = 10054

....

following by


AKSERVER Wed Nov 25 20:44:57 2009
	 Fatal lock manager error: inconsistent lock table version number; found 3,
expected 144, errno: 183


AKSERVER Wed Nov 25 20:44:57 2009
	 Database: C:\PROGRAM FILES\FIREBIRD\SECURITY2.FDB
	 lock manager error
	 inconsistent lock table version number; found 3, expected 144


AKSERVER Wed Nov 25 20:44:57 2009
	 lock manager error


AKSERVER Wed Nov 25 20:44:57 2009
	 inconsistent lock table version number; found 3, expected 144


AKSERVER Wed Nov 25 20:44:57 2009
	 Fatal lock manager error: inconsistent lock table version number; found 3,
expected 144, errno: 183


AKSERVER Wed Nov 25 20:44:57 2009
	 Database: C:\PROGRAM FILES\FIREBIRD\SECURITY2.FDB
	 lock manager error
	 inconsistent lock table version number; found 3, expected 144


AKSERVER Wed Nov 25 20:44:57 2009
	 lock manager error


any idea ??

thanks you by advance for your help !
stephane

--- In firebird-support@yahoogroups.com, Hannes Streicher <hstreicher@...>
wrote:
>
> Guten Tag svanderclock,
>
> am Dienstag, 24. November 2009 um 09:42 schrieben Sie:
>
>
> > let write all the circonstance when the server crash :
>
> > 1/ WinDows 2008 Server & FB classic server 2.1.2
>
> when using firebird 2.1.2  on a windows 2003 server i had a lot of
> problems with the dead connection detection , when a client crashed or
> was not shut down properly firebird 2.1.2 did not detect it.
> (not even over the weekend when all clients were shut turned of)
> it was still reported as connected and the transaction remained open
>
> it went away after upgrading to 2.1.3
> try it
>
> > 3/ Firebird bug ?
> possibly
>
>
> --
> Mit freundlichen Grüssen
> Hannes Streicher                            mailto:HStreicher@...
>

John vd Waeter napsal(a):
> Hi PenWin,
>
> Just to rule out:
>
> I once noticed the same behaviour (sudden slowness of a query), but it
> turned out to be someone on the network was busy copying allmost an
> entire harddisk to the server... IOW, a network congestion problem and a
> very busy server....
>
Nope. This even happens on my standalone development computer.

Pepak

Ann W. Harrison napsal(a):
> Ah.  That's almost the same cost as a deletion - the old version of the
> history record has to be garbage collected.  If there's an index on the
> deleted field in history, the index entry must also be removed.  Since
> there are likely to be LOTS of entries in that index with the same
> the index deletion will be expensive ... less so in 2.0x than 1.5x.
>
I am sure that is so in the general case, but it's unlikely to apply
here - the query I am trying to solve doesn't do any deletions and there
are very few, if any, deletes on any of the two tables concerned.

Pepak

Svein Erling Tysvær napsal(a):
> The only thing that I notice probably could be optimized, is that I doubt it
will ever be useful to use an index for validfrom (due to your description). So,
change to
>
> SELECT d.datakey, MAX(h.histkey) histkey
> FROM data d
> LEFT JOIN history h ON h.code=d.code AND h.deleted=0 AND
> h.validfrom+0<='now' AND h.validto+0>'now'
> WHERE COALESCE(d.code,0)<>COALESCE(h.code,0)
> GROUP BY d.datakey
>
That seems to solve the problem! I have recreated the 9-minute situation
from yesterday as well as I could and got 3.08 seconds with this
modified query! I will do more testing to be sure, but it looks very
promising indeed. Thanks a lot!

Pepak

Morning Pepak,

>> Ann W. Harrison napsal(a):
>> > Ah.  That's almost the same cost as a deletion - the old
>> version of the
>> > history record has to be garbage collected.  If there's an
>> index on the
>> > deleted field in history, the index entry must also be
>> removed.  Since
>> > there are likely to be LOTS of entries in that index with the same
>> > the index deletion will be expensive ... less so in 2.0x than 1.5x.
>> >
>> I am sure that is so in the general case, but it's unlikely to apply
>> here - the query I am trying to solve doesn't do any
>> deletions and there
>> are very few, if any, deletes on any of the two tables concerned.

I think what Ann is telling you is that updating the deleted flag in a
record has almost the same cost as physically deleting the record. Your
update statement will cause a new version of the record to be created
and the old one (or some indicator of it) will require garbage
collection at some point in the future.

It is the garbage collection that is thought to be causing your slow
downs - even if your query at the time of slowdown, is a SELECT.

Cheers,
Norman.

Norman Dunbar
Dunbar IT Consultants Ltd
Orchard House
10a Greenacre Park Mews
Rawdon
Leeds
LS19 6RT

Tel: 0779 3292 984
Tel: 0773 4531 439


Information in this message may be confidential and may be legally privileged.
If you have received this message by mistake, please notify the sender
immediately, delete it and do not copy it to anyone else.   We have checked this
email and its attachments for viruses. But you should still check any attachment
before opening it. We may have to make this message and any reply to it public
if asked to under the Freedom of Information Act, Data Protection Act or for
litigation.  Email messages and attachments sent to or from any Environment
Agency address may also be accessed by someone other than the sender or
recipient, for business purposes.  If we have sent you information and you wish
to use it please read our terms and conditions which you can get by calling us
on 08708 506 506.  Find out more about the Environment Agency at
www.environment-agency.gov.uk

Information in this message may be confidential and may be legally privileged.
If you have received this message by mistake, please notify the sender
immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still
check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under
the Freedom of Information Act, Data Protection Act or for litigation.  Email
messages and attachments sent to or from any Environment Agency address may also
be accessed by someone other than the sender or recipient, for business
purposes.

If we have sent you information and you wish to use it please read our terms and
conditions which you can get by calling us on 08708 506 506.  Find out more
about the Environment Agency at www.environment-agency.gov.uk

Hi

I have a table defined as:

CREATE TABLE POINT_KVIT
(
   ID                 INTEGER         NOT NULL,
   BONNR              INTEGER         DEFAULT 0,
   TEKST              VARCHAR(   100) DEFAULT '' COLLATE NONE,
  CONSTRAINT FK_POINT_KVIT PRIMARY KEY (ID)
);

CREATE ASC INDEX POINT_KVIT_IDX1 ON POINT_KVIT (BONNR);


This tables contains some 24 millions records.


The selectivity to index POINT_KVIT_IDX1 is 0,00000142520 or less


If I do a select like this:

Select
   ID, BonNr, Tekst
from Point_Kvit
Where BonNr = 2236136

It fetches 31 records in hardly no time (0.062 secs) with this plan:
PLAN (POINT_KVIT INDEX (POINT_KVIT_IDX1))


If I on the other hand do a select like this:

Select
   ID, BonNr, Tekst
from Point_Kvit
Where BonNr = 2236136
Order by ID

It fetches the same 31 records, but i now uses 2 seconds to do the same with
this plan:
PLAN (POINT_KVIT ORDER RDB$PRIMARY240 INDEX (POINT_KVIT_IDX1))


My question is, why is there such a big difference in the to above Selects?


I need to have them ordered, so I get them in the same order they where
inserted.
I have for now solved it by doing this select, which is as fast as the first
one:

Select
   ID, BonNr, Tekst,
   BonNr || ID as P
from Point_Kvit
Where BonNr = 2236136
order by 4

Which also have the same PLAN as the first one.



Regards
Michael

Hello Michael,

> I have a table defined as:
>
> CREATE TABLE POINT_KVIT
> (
>  ID                 INTEGER         NOT NULL,
>  BONNR              INTEGER         DEFAULT 0,
>  TEKST              VARCHAR(   100) DEFAULT '' COLLATE NONE,
> CONSTRAINT FK_POINT_KVIT PRIMARY KEY (ID)
> );
>
> CREATE ASC INDEX POINT_KVIT_IDX1 ON POINT_KVIT (BONNR);
>
>
> This tables contains some 24 millions records.
>
>
> The selectivity to index POINT_KVIT_IDX1 is 0,00000142520 or less

Bad, if I recall correctly.

> If I do a select like this:
>
> Select
>  ID, BonNr, Tekst
> from Point_Kvit
> Where BonNr = 2236136
>
> It fetches 31 records in hardly no time (0.062 secs) with this plan:
> PLAN (POINT_KVIT INDEX (POINT_KVIT_IDX1))
>
>
> If I on the other hand do a select like this:
>
> Select
>  ID, BonNr, Tekst
> from Point_Kvit
> Where BonNr = 2236136
> Order by ID
>
> It fetches the same 31 records, but i now uses 2 seconds to do the same
> with this plan:
> PLAN (POINT_KVIT ORDER RDB$PRIMARY240 INDEX (POINT_KVIT_IDX1))
>
>
> My question is, why is there such a big difference in the to above
> Selects?
>
>
> I need to have them ordered, so I get them in the same order they where
> inserted.
> I have for now solved it by doing this select, which is as fast as the
> first one:
>
> Select
>  ID, BonNr, Tekst,
>  BonNr || ID as P
> from Point_Kvit
> Where BonNr = 2236136
> order by 4
>
> Which also have the same PLAN as the first one.

Have you tried a simple

ORDER BY ID + 0

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com

> >
> > The selectivity to index POINT_KVIT_IDX1 is 0,00000142520 or less
>
> Bad, if I recall correctly.

Yes, but I have some that a worse ;-)




Select
   ID, BonNr, Tekst
from Point_Kvit
Where BonNr = 2236136
Order by ID+0


Also works perfect.

But I would like to know why.



Michael

>> > The selectivity to index POINT_KVIT_IDX1 is 0,00000142520 or less
>>
>> Bad, if I recall correctly.
>
> Yes, but I have some that a worse ;-)
>
>
> Select
>  ID, BonNr, Tekst
> from Point_Kvit
> Where BonNr = 2236136
> Order by ID+0
>
>
> Also works perfect.
>
> But I would like to know why.

Because of the expression, it cannot use the index for sorting.

Given that your result returns just a few rows, it should sort those
rows without the index, as hopping arround the index to find the
row, put them in sorting order etc takes more time.

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com

Great - I understand.
Thx.

Have a nice day Martijn :)


>
> Because of the expression, it cannot use the index for sorting.
>
> Given that your result returns just a few rows, it should sort those
> rows without the index, as hopping arround the index to find the
> row, put them in sorting order etc takes more time.
>
> With regards,
>
> Martijn Tonies
> Upscene Productions
> http://www.upscene.com
>
> Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
> Anywhere, MySQL, InterBase, NexusDB and Firebird!
>
> Database questions? Check the forum:
> http://www.databasedevelopmentforum.com
>

Hi,

I have a multithreaded program running atop IBPP on Firebird 2.1.1.

The problem is that firebird stop working and the log is full of this statement:

	 HMI-MOP-AXX (Server) Thu Nov 12 13:19:34 2009
		 INET/inet_error: read errno = 10054


the IBPP log says:

	 *** IBPP::SQLException ***
	 Context: Transaction::Start

	 SQL Message : -902
	 Unsuccessful execution caused by a system error that precludes
	 successful execution of subsequent statements

	 Engine Code    : 335544721
	 Engine Message :
	 Unable to complete network request to host "localhost".
	 Error writing data to the connection.
	 An existing connection was forcibly closed by the remote host.


we're unable to keep the server alive for more than a couple of hours at most.

the program and firebird is running on the same machine, using a socket.

does anybody know how to solve this? it's quite critical.

Firebird was supposed to have substituted mysql but the customer is not happy
with the situation so we might have to roll back the project.

Bad, since i consider FB a better DB than Mysql.

I've found this thread on the subject:

http://www.mail-archive.com/firebird-net-provider@lists.sourceforge.net/msg06119\
.html

which says the problem should be resolved. but as far as i can tell it's not.

I know this is off topic but is IBPP still maintained and is it threadsafe?


best regards

Kim Gabrielsen

> we're unable to keep the server alive for more than a couple of hours at most.
> the program and firebird is running on the same machine, using a socket.
> does anybody know how to solve this? it's quite critical.

    Uninstall NOD32 and reinstall clean TCP/IP stack.

    SY, SD.

sorry,

 

i'm not  a windows guy.

 

what do you meen by 'unistall NOD32'.

 

is it a windows standard component?

 

kim

 

>> we're unable to keep the server alive for more than a couple
of hours at

>> most.

>> the program and firebird is running on the same machine, using a
socket.

>> does anybody know how to solve this? it's quite critical.

>

>    Uninstall NOD32 and reinstall clean TCP/IP stack.

>

>    SY, SD.

>

>

> ------------------------------------

>

> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>

> Visit http://www.firebirdsql.org and click the Resources item

> on the main (top) menu.  Try Knowledgebase and FAQ links !

>

> Also search the knowledgebases at http://www.ibphoenix.com

>

> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> Yahoo! Groups Links

>

>     http://groups.yahoo.com/group/firebird-support/

>

>     Individual Email | Traditional

>

>     http://groups.yahoo.com/group/firebird-support/join

>     (Yahoo! ID required)

>

>     firebird-support-digest@yahoogroups.com

>     firebird-support-fullfeatured@yahoogroups.com

>

>     firebird-support-unsubscribe@yahoogroups.com

>

>     http://docs.yahoo.com/info/terms/

>

>


[Non-text portions of this message have been removed]

> i'm not  a windows guy.

    Why have you installed Firebird on Windows then?

> what do you meen by 'unistall NOD32'.
> is it a windows standard component?

    No this is very wide spread antivirus software which is known to make
troubles.

    SY, SD.

At 09:51 PM 26/11/2009, you wrote:
>sorry,
>
>i'm not  a windows guy.
>
>what do you meen by 'unistall NOD32'.
>
>is it a windows standard component?

No, it's a free anti-virus program that runs with a custom Firebird as its
back-end and it causes conflicts with user installations of Firebird.  Since
NOD32 causes the problem you describe, it looks as though Dmitry is guessing
that NOD32 is present on your customer's machine and is stealing port 3050.

Why are you still using Fb 2.1.1, anyway?

./heLen

> No, it's a free anti-virus program that runs with a custom Firebird as its
back-end and it causes conflicts with user installations of Firebird.  Since
NOD32 causes the problem you describe, it looks as though Dmitry is guessing
that NOD32 is present on your customer's machine and is stealing port 3050.

    Actually, source of problems (AFAIK) not back-end Firebird but bugs
in IMON module.

    SY, SD.

customer demand :-(

 

the environment is a semi embedded machine, so no antivirus as far as
i'm concerned.

 

but i'll investigate

 

kim

 

>> i'm not  a windows guy.

>

>    Why have you installed Firebird on Windows then?

>

>> what do you meen by 'unistall NOD32'.

>> is it a windows standard component?

>

>    No this is very wide spread antivirus software which is known to
make

> troubles.

>

>    SY, SD.

>

>

> ------------------------------------

>

> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>

> Visit http://www.firebirdsql.org and click the Resources item

> on the main (top) menu.  Try Knowledgebase and FAQ links !

>

> Also search the knowledgebases at http://www.ibphoenix.com

>

> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> Yahoo! Groups Links

>

>     http://groups.yahoo.com/group/firebird-support/

>

>     Individual Email | Traditional

>

>     http://groups.yahoo.com/group/firebird-support/join

>     (Yahoo! ID required)

>

>     firebird-support-digest@yahoogroups.com

>     firebird-support-fullfeatured@yahoogroups.com

>

>     firebird-support-unsubscribe@yahoogroups.com

>

>     http://docs.yahoo.com/info/terms/

>

>


[Non-text portions of this message have been removed]

we started development of this solution early april and only 2.1.1 vas
available.

 

i know the customer is looking into upgrading.

 

do you know if i can upgrade FB from 2.1.1 to 2.1.3 with regard to
ibpp? will it cause any problems to do so?

 

 

 

> At 09:51 PM 26/11/2009, you wrote:

>>sorry,

>>

>>i'm not  a windows guy.

>>

>>what do you meen by 'unistall NOD32'.

>>

>>is it a windows standard component?

>

> No, it's a free anti-virus program that runs with a custom Firebird
as its

> back-end and it causes conflicts with user installations of Firebird.


> Since NOD32 causes the problem you describe, it looks as though
Dmitry is

> guessing that NOD32 is present on your customer's machine and is
stealing

> port 3050.

>

> Why are you still using Fb 2.1.1, anyway?

>

> ./heLen

>

>

>

>


[Non-text portions of this message have been removed]

At 10:22 PM 26/11/2009, you wrote:

>we started development of this solution early april and only 2.1.1 vas
>available.

Not true.  V.2.1.2 was released on April 1.

>i know the customer is looking into upgrading.

Actually, a sub-release isn't an upgrade, as such, since nothing changes except
bugs.  That said, programmers sometimes rely on the perpetuation of bugs of long
standing, albeit this is never recommended.

>do you know if i can upgrade FB from 2.1.1 to 2.1.3 with regard to
>ibpp? will it cause any problems to do so?

Put it this way, if IBPP has a problem with a sub-release then IBPP has a bug. 
But ask in the IBPP forum about any issues.

You should at least read through the release notes of V.2.1.3.  You will find
all the bug fixes for all sub-releases in the separate Bug Fixes document. 
There have been a LOT of them.

./heLen

> I have a multithreaded program running atop IBPP on Firebird 2.1.1.

     Do you play by the MT-safe rules ? The easiest is to not share same
attachment
by different theads or to manually syncronize access to it. Also you should
serialize
calls of attach\detach database.

     And upgrade up to 2.1.3, it is safe.

> the program and firebird is running on the same machine, using a socket.

     So, use local protocol (XNET) for more speed.

> does anybody know how to solve this? it's quite critical.

     It depends. And we should know more info from you...

> i consider FB a better DB than Mysql.

     We have the same idea, you are not alone ;)

> I've found this thread on the subject:
>
>
http://www.mail-archive.com/firebird-net-provider@lists.sourceforge.net/msg06119\
.html
>
> which says the problem should be resolved. but as far as i can tell it's not.

     It was about .Net provider. Since you used IBPP its not for you ;)

Regards,
Vlad

--- In firebird-support@yahoogroups.com, "svanderclock" <svanderclock@...>
wrote:
>
> is it any other option instead of global tempory table? store the table in
other file ?
>
> stephane
>

external table files??

CREATE TABLE table [EXTERNAL [FILE] 'filespec']
(<col_def> [, <col_def> | <tconstraint> …]);

Hello,

I'm not sure why do I get this message "The result of an integer
operation caused the most significant bit of the result to carry."
I'm using FB 2.1.3

This is the line that raises exception:

V_DIFF = - V_AMOUNT * V_SIGN * V_RATE;

These are declarations

declare variable v_sign numeric(18,2);
declare variable v_diff numeric(18,2);
declare variable v_rate numeric(18,10);
declare variable v_amount numeric(18,2);



Using

CAST((V_AMOUNT * V_SIGN * V_RATE) as numeric(18,2)

doesn't help

> I'm not sure why do I get this message "The result of an integer
> operation caused the most significant bit of the result to carry."
> I'm using FB 2.1.3
>
> This is the line that raises exception:
>
> V_DIFF = - V_AMOUNT * V_SIGN * V_RATE;
>
> These are declarations
>
> declare variable v_sign numeric(18,2);
> declare variable v_diff numeric(18,2);
> declare variable v_rate numeric(18,10);
> declare variable v_amount numeric(18,2);

    numeric(18,2)*numeric(18,2)*numeric(18,10) = numeric(18,14).

> Using
>
> CAST((V_AMOUNT * V_SIGN * V_RATE) as numeric(18,2)
>
> doesn't help

    Cast result of one multiplication.

    SY, SD.