firebird-test — Firebird engine testing, test flight/suite discussion/information

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3385) Server is Crashing after cannot start sweep thread (0)

[Andre v. Z. <an...@sp...>]

Thanks Dmitry for your response.

I was running the stable release of Firebird 2.5.0 but there were some
issues with views and stored procedures that I could not ignore.

I'm running a 32bit 2.5.1.26208, I understand it is a snapshot but it seemed
quite stable for what was needed in testing.

If the server is crashing out due to virtual memory problems, would
restarting the machine each week be a valid solution ?   I prefer to run a
Firebird Server on Linux but how should this be handled on Windows ?

I'm interested in what would cause the virtual memory to be used,  I'm
assuming from what you say this is not a Firebird bug ?


On Tue, Mar 15, 2011 at 11:54 AM, Dmitry Yemanov (JIRA) <
tr...@fi...> wrote:

>
>    [
> http://tracker.firebirdsql.org/browse/CORE-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22932#action_22932]
>
> Dmitry Yemanov commented on CORE-3385:
> --------------------------------------
>
> I removed the over-longish firebird.log contents, please attach it as a
> separate file.
>
> > Server is Crashing after cannot start sweep thread (0)
> > ------------------------------------------------------
> >
> >                 Key: CORE-3385
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-3385
> >             Project: Firebird Core
> >          Issue Type: Bug
> >      Security Level: Developers(Visible only to project developers (and
> administrators))
> >          Components: Engine
> >    Affects Versions: 2.5.1
> >         Environment: Windows 7 Professional
> >            Reporter: Andre van Zuydam
> >
> > We have a test system running on 2.5.1 snapshot,  each week (plus minus 7
> - 8 days) apart we have to manually restart  / initialize the Firebird
> service which crashes out.
> >  Looking into the logs points to a possible network which we have had a
> look at, unfortunatelly I get  INET/inet_error: read errno = 10054 on
> localhost development machine every time I work.
> > One possible cause is perhaps the sweep that failed ?  The five clients
> were connected but could not query the server after such an incident  which
> also makes the problem strange.
> > The logs of the past week since the last crash and today are below.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


-- 
Andre van Zuydam
Spiceware Software (Pty) Ltd
<https://www.ohloh.net/accounts/75973?ref=Tiny>
=============================
Email:  an...@sp...
Tel:    +27 83 646 4535
Fax:   +27 86 682 6944
Web:    www.spiceware.co.za
=============================

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3074) Wrong Page type, expected 6 found 5

[Neil P. <nei...@cs...>]

I haven't had much time to check into this. One thing I have noticed is that it seems to occur, almost on demand, if we use IBOConsole to either select or update a number of records in a large database of approx 10Gb size.

I should have a bit more time to check into this shortly.

Best Regards,

Neil Pickles - ne...@cs...
Technical Director
CSY Retail Systems Limited
 
http://www.csy.co.uk
 
This email may contain privileged information which is for the intended recipient only. If you should receive this email in error you must not divulge or use any of the information it may contain but destroy it immediately and notify the sender of the error.
Internet communications are not secure and therefore the CSY Group does not accept legal responsibility for the contents of this message.
Although the CSY Group operates anti-virus programs, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed.
Agreements binding CSY Group companies may not be concluded by means of e-mail communication. 
Any opinions expressed are those of the author and are not necessarily those of the company. 
 
Registered in England No. 2391386, Vat No GB 520 7385 59 Registered Address: CSY House, Daleside Road, Nottingham, NG2 4DH


-----Original Message-----
From: Dmitry Yemanov (JIRA) [mailto:tr...@fi...] 
Sent: 14 February 2011 12:34
To: Neil Pickles
Subject: [FB-Tracker] Commented: (CORE-3074) Wrong Page type, expected 6 found 5


    [ http://tracker.firebirdsql.org/browse/CORE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22724#action_22724 ] 

Dmitry Yemanov commented on CORE-3074:
--------------------------------------

Neil, any news about facing this issue with recent snapshot builds?

> Wrong Page type, expected 6 found 5
> -----------------------------------
>
>                 Key: CORE-3074
>                 URL: http://tracker.firebirdsql.org/browse/CORE-3074
>             Project: Firebird Core
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: 2.1.4
>         Environment: Windows XP SP2/SP3 with Super Server
>            Reporter: Neil Pickles
>         Attachments: firebird 214 wrong pagetype error screenshot.jpg
>
>
> I am seeing a very similar issue to CORE-2616
> The following error appeared this morning when trying to attach to the database.
> Database file appears corrupt (C:\PROGRAM FILES\FIREBIRD\FIREBIRD_2_1\SECURITY2.FDB) 
> wrong page type 
> page 67 is of wrong type (expected 6, found 5) 
> database file appears corrupt (garbage). 
> The garbage at the end of the 'database file appears corrupt' message seems to be some random accented characters, you can see them in the error screenshot attached. 
> I am using a patched version of v2.1.4 as supplied by Vlad Khorshun to resolve Core-3050. I assumed that the fix for CORE-2616 would be in that version, maybe it is and this is a new issue. The version number of that version is 2.1.4.18314 but has been patched by Vlad without incrementing the version number I think.
> I have previously seen this more frequently in v2.1.3 SS where it was acknowledged as an error but should have been fixed in v2.1.4, but this is the first time I have seen it using the patched v2.1.4 SS I have been using on Windows XP SP2 or SP3. Existing users can use the system fine, it is only new users that see the error until the server gets restarted. 
> If I restart the server everything then works fine again. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Firebird-test] [[FB-Tracker] Account signup]

[Eric G. <ant...@ma...>]

Bonjour,

Notre politique de sécurité et de lutte contre les spams nécessite qu'un expéditeur externe soit reconnu pour que ses messages soient acceptés. 

Vous recevez ainsi ce message car c'est la toute première fois que vous m'adressez un email.

Pour que vos messages me soient transmis, je vous invite à simplement : http://asp9.mailinblack.com/v/?AA4D822E583&tmstp=20110208102812&tk=message_confirm&tkid=759102&lang=1

Cette identification n’est à faire qu'une seule fois. Tous vos futurs messages me parviendront directement.

Nous vous remercions de participer avec nous à la lutte contre le spam.

Recevez mes sincères salutations.

Eric GALLEY

--------------------
Dear Sir, Madam,

Our policy in security and the fight against spam requires our outside senders to be recognized in order for their messages to be accepted.

You are certainly receiving this message because it is the very first time that you have sent me a mail.

For your messages to be forwarded to me, simply : http://asp9.mailinblack.com/v/?AA4D822E583&tmstp=20110208102812&tk=message_confirm&tkid=759102&lang=2

This identification needs only to be done once. All your future messages will come straight to me.

Thank you very much for playing your part in the fight against spam.

Sincerely yours,

Eric GALLEY

----------------------
Powered by MailInBlack

Re: [Firebird-test] [FB-Tracker] Resolved: (CORE-3337) problem in performing case statement

[mauro r. <m....@un...>]

...sorry to have been to fast in submit the report.

At least I learned how to interface with firebird developer group.

Thank you for very fast answer.
Mauro.


----- Original Message ----- 
From: "Adriano dos Santos Fernandes (JIRA)" <tr...@fi...>
To: "Russo Mauro" <usn...@ma...>
Sent: Saturday, February 05, 2011 3:06 PM
Subject: [FB-Tracker] Resolved: (CORE-3337) problem in performing case 
statement


>
>     [ 
> http://tracker.firebirdsql.org/browse/CORE-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Adriano dos Santos Fernandes resolved CORE-3337.
> ------------------------------------------------
>
>    Resolution: Won't Fix
>
> There is no problem here.
>
> The first form compares NULL = NULL, which is obviously false.
>
> The first form equivalent is:
>  select distinct (case when NULL = NULL then 0 else 1 end) as v from 
> RDB$DATABASE
>
>
>> problem in performing case statement
>> ------------------------------------
>>
>>                 Key: CORE-3337
>>                 URL: http://tracker.firebirdsql.org/browse/CORE-3337
>>             Project: Firebird Core
>>          Issue Type: Bug
>>          Components: Engine
>>    Affects Versions: 2.1.1
>>            Reporter: mauro russo
>>
>> the query
>> select distinct (case NULL when NULL then 0 else 1 end) as v from 
>> RDB$DATABASE
>> wrongly returns 1
>> whereas the query
>> select distinct (case when NULL is NULL then 0 else 1 end) as v from 
>> RDB$DATABASE
>> correctly returns 0
>
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: 
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
> 

Re: [Firebird-test] [FB-Tracker] Resolved: (CORE-3306) Invariant sub-query is treated as variant thus causing multiple invokations of a nested stored procedure

[Jean-Baptiste S. \(C. IT S. SA\) <jb....@cs...>]

Thank you for the super fast answer !

What is the time schedule for release V2.5.1?

Cordiales salutations

Jean-Baptiste Simmen

CSE IT Solutions SA, Alte Lyssstrasse 2, 3270 Aarberg
téléphone: 032/387 19 20, téléfax: 032/387 19 98
jb....@cs..., www.cse.ch


-----Ursprüngliche Nachricht-----
Von: Adriano dos Santos Fernandes (JIRA) [mailto:tr...@fi...]
Gesendet: Mittwoch, 12. Januar 2011 01:18
An: jb....@cs...
Betreff: [FB-Tracker] Resolved: (CORE-3306) Invariant sub-query is treated 
as variant thus causing multiple invokations of a nested stored procedure


     [ 
http://tracker.firebirdsql.org/browse/CORE-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adriano dos Santos Fernandes resolved CORE-3306.
------------------------------------------------

    Fix Version/s: 2.5.1
                   3.0 Alpha 1
       Resolution: Fixed

> Invariant sub-query is treated as variant thus causing multiple 
> invokations of a nested stored procedure
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CORE-3306
>                 URL: http://tracker.firebirdsql.org/browse/CORE-3306
>             Project: Firebird Core
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: 2.5.0
>         Environment: Found and Tested on MS Windows XP 
> (Firebird-2.5.0.26074_1_Win32) and Server 2008 
> (Firebird-2.5.0.26074_1_x64 )
>            Reporter: Jean-Baptiste Simmen
>            Assignee: Adriano dos Santos Fernandes
>             Fix For: 2.5.1, 3.0 Alpha 1
>
>
> The Behaviour about a where statement with static content have change from 
> Firebird 1.5/2.1 to 2.5 and have a massiv impact in our case. The static 
> statement like (select sValue From spr_test('SIMSIM')) is evaluated 1 time 
> in firebird 1.5 and 2.1, the number of row in the from-clause with 
> firebird 2.5 (about 45'000 in our case).
> You can test it with the following script:
> -------------------------------------------------------------------------------
> -- Init
> -------------------------------------------------------------------------------
> Create Table tt_table(Field1 varchar(100));
> go
> Create Or Alter PROCEDURE SPR_TEST (pName Varchar(2000)) RETURNS (sValue 
> Varchar(255)) AS
> BEGIN
>   Insert Into tt_table(field1) values(:pName);
>   sValue=:pName;
>   suspend;
> End
> go
> -------------------------------------------------------------------------------
> -- Call procedure
> -------------------------------------------------------------------------------
> Select count(*)
> from rdb$types
> where rdb$field_name like (select sValue From spr_test('SIMSIM'))
> go
> -------------------------------------------------------------------------------
> -- Result is 1 with Firebird 1.5 and 2.1, 225 with Firebird 2.5
> -------------------------------------------------------------------------------
> Select count(*) From tt_table
> go
> -------------------------------------------------------------------------------
> -- Clean
> -------------------------------------------------------------------------------
> Drop Procedure spr_test
> go
> Drop Table tt_table
> go
> Thank you for your big work with Firebird, its a very good thing!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Firebird-test] [Firebird-net-provider] [FB-Tracker] Created: (DNET-349) IscException throws. Error message: \"internal gds software consistency check (cannot find tip page (165), file: tra.cpp line: 2500)\"

[Lee L. <lla...@co...>]

Hello,
I am getting this same error (event) on my server.  It looks like the ticket is still open, do you know where I should look for resolution?


Lee Lasseigne | Financial Systems Consultant
Compushare, Inc. |
5400 S Patton Drive,Suite 4A, Lisle, IL 60532
T 630 967-3104
www.compushare.com<http://www.compushare.com/>

SMART Technology Management Solutions for the Financial Services Industry

This e-mail and any attachments or files transmitted with it contain information that
is confidential and may be privileged. It is intended only for the addressee(s) named
above. If you receive this e-mail in error, please do not read, copy or disseminate it in
any manner. If you are not the intended recipient, any disclosure, copying, distribution
or use of the contents of this information is prohibited. Please reply to the message
immediately by informing the sender that the message was misdirected. After replying,
please erase it from your computer system. Your assistance in correcting this error
is appreciated.

Re: [Firebird-test] [FB-Tracker] Прокомментирован: (CORE-3119) 100% CPU USAGE with Unilimited Loop & Index corrupted

[Vlad K. <hv...@us...>]

    Hi, Stephane

    I already reproduced bug (thanks to Artem's case) and the bug reason i 
found is fully fit into your case too. The bug happens when client asks for 
secondary connection for event's processing but never connects to it.
In your case firewall blocked incoming connection request and in Artem's 
case application hungs before it make connection request. After timeout 
server closed both event's socket and (bug!) main listener socket too.

    I sent fixed fb_inet_server to Artem and waiting feedback from him.
Do you want to test it too (x64, iirc) ? 

Regarsd,
Vlad

Re: [Firebird-test] Query Cache Idea

[Ray H. <rh...@ro...>]

On Mon, 2010-10-25 at 09:58 -0400, Jim Starkey wrote:
> This is an interest idea.  Would you be willing to move it to the 
> architecture list? 

Lord knows why I received this one, but if it is what it implies - I
have been cacheing queries on the client side for years.

Hope you and Ann are well.

Ray

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3214) database page errors and record level error when updating records with blobs several times

[Alexandre P. <apa...@gm...>]

I created the table and applied the operations I mentioned. Afterwards, the
database was mich bigger than it should be, and it took a very long time to
open the table using Database Desktop Pro. So I run a validation (again from
DDP) and it advised me that there were errors.

2010/11/8 Dmitry Yemanov (JIRA) <tr...@fi...>

>
>    [
> http://tracker.firebirdsql.org/browse/CORE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22024#action_22024]
>
> Dmitry Yemanov commented on CORE-3214:
> --------------------------------------
>
> What are the page errors you mention? How did you know about them?
>
> > database page errors and record level error when updating records with
> blobs several times
> >
> ------------------------------------------------------------------------------------------
> >
> >                 Key: CORE-3214
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-3214
> >             Project: Firebird Core
> >          Issue Type: Bug
> >    Affects Versions: 2.5.0
> >         Environment: Windows XP Professional SP3
> >            Reporter: Alexandre Palmeira
> >
> > I have a database with only one table:
> > CREATE TABLE IMP_PESSOAL_NDX
> > (
> >   PALAVRA              INTEGER         NOT NULL,
> >   N                    INTEGER,
> >   VERSAO              SMALLINT,
> >   INDICE                  BLOB SUB_TYPE 0 SEGMENT SIZE 80,
> >  CONSTRAINT PK_IMP_PESSOAL_NDX PRIMARY KEY (PALAVRA)
> > );
> > INDICE is a list of integers. My program reads a list of 300.000 pairs
> (P, N), locates or inserts the record with PALAVRA=P, reads the sorted
> integer list in INDICE, adds N to the list and saves it back to INDICE. (I
> am not sure when the alterations are commited.)
> > At the end of the process, there are several page errors. The database is
> several times larger than it should be, and I am unable to back it up.
> > The issue was also present in version 2.1.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

Re: [Firebird-test] [FB-Tracker] Commented: (ODBC-93) Error connecting to existing database using Windows Server 2008 R2 / 64 bit

[Sue A. <sa...@en...>]

No. 

The only "gd..." dll in c:\windows\system32 is gdi32.dll.

Should I try copying gds32.dll there? If so, where would it have installed to?

Thanks!
Sue

-----Original Message-----
From: Alexander Potapchenko (JIRA) [mailto:tr...@fi...] 
Sent: Thursday, November 04, 2010 2:34 PM
To: Sue Allen
Subject: [FB-Tracker] Commented: (ODBC-93) Error connecting to existing database using Windows Server 2008 R2 / 64 bit


    [ http://tracker.firebirdsql.org/browse/ODBC-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22015#action_22015 ] 

Alexander Potapchenko commented on ODBC-93:
-------------------------------------------

Do you have 64-bit gds32.dll (fbclient.dll) in system32?
Unable to connect to data source: library 'gds32.dll' failed to load" - ODBC driver can not load (find) a client library.

> Error connecting to existing database using Windows Server 2008 R2 / 64 bit
> ---------------------------------------------------------------------------
>
>                 Key: ODBC-93
>                 URL: http://tracker.firebirdsql.org/browse/ODBC-93
>             Project: ODBC Driver
>          Issue Type: Bug
>    Affects Versions: 2.0 RC1
>         Environment: Windows Server 2008 R2
>            Reporter: Sue Allen
>            Priority: Blocker
>
> We have an existing ODBC connection to a database on our production server. We are in the process of setting up a new server and are not able to set up an ODBC connection to the same database. We are using the same userid, password, and database.
> Creating the base ODBC connection information succeeds, but all attempts to actually test / connect to the database fail.
> Upon clicking the "Services" button and going to the "Users" tab, we receive the following error:
>     "sql code -904, fbcode 335544375 - Unable to connect to data source: library 'gds32.dll' failed to load"
> I did download the version of ODBCFB.DLL from issue # ODBC-72 this morning; this did not fix the error.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3212) Error compile 2.5 for FreeBSD

[Александр Е. <mr....@gm...>]

Excuse I hasn't absolutely correctly asked a question. I'm from Russian.
Compile as root and (or) non-root the same error.

2010/11/2 Alexander Peshkov (JIRA) <tr...@fi...>

>
>    [
> http://tracker.firebirdsql.org/browse/CORE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22001#action_22001]
>
> Alexander Peshkov commented on CORE-3212:
> -----------------------------------------
>
> What happens if we compile as root and later try to run as non-root - does
> it start or not?
>
>
> > Error compile 2.5 for FreeBSD
> > -----------------------------
> >
> >                 Key: CORE-3212
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-3212
> >             Project: Firebird Core
> >          Issue Type: Bug
> >    Affects Versions: 2.5.0
> >         Environment: FreeBSD 8.1-STABLE
> >            Reporter: Efremov Aleksandr Valer'evich
> >            Assignee: Alexander Peshkov
> >
> > If we compile fresh 2.5 not as root, we get
> > gmake -f ../gen/Makefile.embed.util ../gen/firebird/bin/create_db
> > gmake[3]: Entering directory
> `/home/user/firebird/firebird2.5/firebird2/gen'
> > gmake[3]: `../gen/firebird/bin/create_db' is up to date.
> > gmake[3]: Leaving directory
> `/home/user/firebird/firebird2.5/firebird2/gen'
> > rm -f empty.fdb
> > ../gen/firebird/bin/create_db empty.fdb
> > Fatal lock manager error: mutex init failed, errno: 2
> > --No such file or directory
> > gmake[2]: *** [empty.fdb] Segmentation fault: 11 (core dumped)
> > gmake[2]: *** Deleting file `empty.fdb'
> > gmake[2]: Leaving directory
> `/home/user/firebird/firebird2.5/firebird2/gen'
> > gmake[1]: *** [empty_db] Error 2
> > gmake[1]: Leaving directory
> `/home/user/firebird/firebird2.5/firebird2/gen'
> > gmake: *** [firebird] Error 2
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

Re: [Firebird-test] [FB-Tracker] Updated: (ODBC-64) Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.

[Christian S. <c.s...@bc...>]

It works, thank you
Christian Schön 

-----Ursprüngliche Nachricht-----
Von: Alexander Potapchenko (JIRA) [mailto:tr...@fi...] 
Gesendet: Mittwoch, 27. Oktober 2010 11:49
An: Christian Schoen
Betreff: [FB-Tracker] Updated: (ODBC-64) Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.


     [ http://tracker.firebirdsql.org/browse/ODBC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Potapchenko updated ODBC-64:
--------------------------------------

    Attachment:     (was: OdbcFb.zip)

> Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.
> ----------------------------------------------------------------------
> --------------------------------------------------
>
>                 Key: ODBC-64
>                 URL: http://tracker.firebirdsql.org/browse/ODBC-64
>             Project: ODBC Driver
>          Issue Type: Bug
>    Affects Versions: 2.0 RC1
>         Environment: MS XP SP3
> MS Access 2000
>            Reporter: Christian
>            Assignee: Alexander Potapchenko
>         Attachments: OdbcFb.zip
>
>
> Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.
> If additional text is added (UPDATE) to memo field the full information vanishes except the first character.
> If new text is added to memo field (INSERT) the full information vanishes except the first character.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Firebird-test] [FB-Tracker] Resolved: (ODBC-64) Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.

[Christian S. <c.s...@bc...>]

Thank you,
Give me some time to check it
Best regards
Christian Schön 

-----Ursprüngliche Nachricht-----
Von: Alexander Potapchenko (JIRA) [mailto:tr...@fi...] 
Gesendet: Mittwoch, 27. Oktober 2010 12:10
An: Christian Schoen
Betreff: [FB-Tracker] Resolved: (ODBC-64) Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.


     [ http://tracker.firebirdsql.org/browse/ODBC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Potapchenko resolved ODBC-64.
---------------------------------------

    Fix Version/s: 2.0 RC2 
       Resolution: Fixed

> Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.
> ----------------------------------------------------------------------
> --------------------------------------------------
>
>                 Key: ODBC-64
>                 URL: http://tracker.firebirdsql.org/browse/ODBC-64
>             Project: ODBC Driver
>          Issue Type: Bug
>    Affects Versions: 2.0 RC1
>         Environment: MS XP SP3
> MS Access 2000
>            Reporter: Christian
>            Assignee: Alexander Potapchenko
>             Fix For: 2.0 RC2
>
>         Attachments: OdbcFb.zip
>
>
> Connecting from MS-Access 2000 to Firebird 2.0 database via ODBC dricer 2.0 RC1 delievers faulty results in memo fields.
> If additional text is added (UPDATE) to memo field the full information vanishes except the first character.
> If new text is added to memo field (INSERT) the full information vanishes except the first character.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Firebird-test] Query Cache Idea

[Jim S. <jst...@ni...>]

  This is an interest idea.  Would you be willing to move it to the 
architecture list?

-- 
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376

Re: [Firebird-test] [Firebird-devel] new bench tools

[Philippe M. <mak...@fi...>]

marius,
> I think it can be use full , also i try to run the tpch tests on my machines
> and i try to to start it with 2.5.0 (we can move the discussion there
> or on python firebird)

you need to create metadata, use --setup

python ibench.py --db_user=sysdba --db_password=masterkey
--db_name=/tmp/test.fdb --setup

and for a first run, try low values :
--max_rows=100000 --rows_per_report=10000
for example

but we can move this on Firebird-testlist : fir...@li...
http://www.firebirdsql.org/index.php?op=lists

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40

[Ray H. <rh...@ro...>]

On Wed, 2010-09-08 at 06:58 -0400, Ray Holme wrote:
> Sean has no problem and neither did I - sorry.

Great, sorry that I left the healing index in the DB.

drop index fix_bug1;

will make things work like they did without a workaround.

:=]

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40

[Dmitry Y. <fir...@ya...>]

08.09.2010 21:22, Leyne, Sean wrote:
>
> I never said that I tried to restore the DB -- I didn't.

I did and finally succeeded. But the database is useless on a Windows 
server as the missing UDFs *are* important to use the test case (table 
metadata cannot be loaded without them, even if the query doesn't refer 
to any of those computed columns).


Dmitry

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40 - Email found in subject

[Leyne, S. <Se...@br...>]

Ray,

I never said that I tried to restore the DB -- I didn't.


Sean


> -----Original Message-----
> From: Ray Holme [mailto:rh...@ro...]
> Sent: September-08-10 6:58 AM
> To: Dmitry Yemanov (JIRA)
> Subject: Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127)
> somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to
> the optimizer - I had a query that ran in 2 seconds take 40 - Email found in
> subject
> 
> Sean has no problem and neither did I - sorry.
> 
> ray@rainbow FB_bug]$ ls
> addindex.ddl  out.txt  test_xx  vetAdmin.gbak.gz  vetAdmin.so [ray@rainbow
> FB_bug]$ gunzip vetAdmin.gbak.gz [ray@rainbow FB_bug]$ gbak -rep -z
> vetAdmin.gbak test.fdb gbak:gbak version LI-V2.0.5.13206 Firebird 2.0
> gbak:    Version(s) for database "test.fdb"
> 	Firebird/linux AMD64 (access method), version "LI-V2.0.5.13206
> Firebird 2.0"
> 	on disk structure version 11.0
> [ray@rainbow FB_bug]$ ls -l
> total 21308
> -rw-r--r--. 1 ray staff      146 2010-09-07 17:33 addindex.ddl
> -rw-r--r--. 1 ray staff     1077 2010-09-07 17:33 out.txt
> -rw-rw----. 1 ray staff 16545792 2010-09-08 06:56 test.fdb
> -rw-r--r--. 1 ray staff      513 2010-09-07 17:32 test_xx
> -rw-r--r--. 1 ray staff  5242368 2010-09-07 17:33 vetAdmin.gbak
> -rw-r--r--. 1 ray staff    14816 2010-09-07 17:33 vetAdmin.so
> 
> 
> 
> 
> On Wed, 2010-09-08 at 03:28 +0000, Dmitry Yemanov (JIRA) wrote:
> > [ http://tracker.firebirdsql.org/browse/CORE-
> 3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=21688#action_21688 ]
> >
> > Dmitry Yemanov commented on CORE-3127:
> > --------------------------------------
> >
> > The attached backup fails to restore with v2.0.5:
> >
> > unsuccessful metadata update.
> >      TABLE INVOICE_LINES.
> >      Can't have relation with only computed fields or constraints.
> >
> >
> > > somewhere after 2.0.5 - apparently 2.0.6 a significant change was made
> to the optimizer - I had a query that ran in 2 seconds take 40
> > > -----------------------------------------------------------------------------------------
> --------------------------------------------
> > >
> > >                 Key: CORE-3127
> > >                 URL: http://tracker.firebirdsql.org/browse/CORE-3127
> > >             Project: Firebird Core
> > >          Issue Type: Bug
> > >          Components: Engine
> > >         Environment: Reproducible with isql - tested in 2.0.6 and 2.1.3 - on
> MAC, Linux and PC platforms
> > >            Reporter: Ray Holme
> > >         Attachments: addindex.ddl, out.txt, test_xx, vetAdmin.gbak.gz,
> vetAdmin.so
> > >
> > >
> > > I have a DB, copy of the Linux UDF (can be eliminated as computed fields
> not referenced in query), copy of the query, timings under 2 releases of
> Linux (first seen on PC, then on MAC, but confirmed here on  Linux), and an
> add Index statement that works around the problem for us.
> >
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-test

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40

[Ray H. <rh...@ro...>]

On Tue, 2010-09-07 at 22:23 +0000, Sean Leyne (JIRA) wrote:
> The original SQL seems to be missing the relationship between patients
> and people.  How are the tables related?

Sean,

If you are wondering why I do NOT use foreign keys - I DO NOT.

Instead I use trigger code and procedures to verify the foreign key.

  a) foreign key indices may not be dropped for a hard load and on the
secondary table(s) - they can be a stupid waste (see below)

  b) foreign key indices sometimes confuse the optimizer into
     using then when it would be a VERY bad idea
     e.g. if you had a large DB of USA people with a foreign
          key on state, and referenced state as a requirement
          in the query - you would have been better off with
          a natural run

I have been burned before MANY TIMES and have been using Interbase since
release 2.0. I specialize in performance and times where things in a DB
are sometimes slow.

Ray

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40

[Ray H. <rh...@ro...>]

Below are the timings. Sorry Sean, nice try but not a real big win. I
saved about .5 seconds using EXISTS. PS as you can see below the
original 2.0.5 query takes .15 seconds compared to 31 seconds under
2.1.3 - THIS IS A HUGE PERFORMANCE DEGRADATION. While I have both
installed on my machine, I run 2.0.5.


timings orig query 2.0.5 with fix
 PLAN (PO INDEX (INDX_PAON2))
 PLAN JOIN (PT NATURAL, P NATURAL)

 real	0m0.157s
 user	0m0.114s
 sys	0m0.028s

timings orig query 2.1.3 WITH fix
 PLAN (PO INDEX (INDX_PAON2))
 PLAN JOIN (PT INDEX (FIX_BUG1), P NATURAL)

 real	0m0.489s
 user	0m0.097s
 sys	0m0.053s

timings orig query 2.1.3 without fix (added index)
PLAN (PO INDEX (INDX_PAON2))
PLAN JOIN (P NATURAL, PT NATURAL)

 real	0m31.276s
 user	0m28.578s
 sys	0m2.642s

timings with 2.1.3 EXISTS query without fix
 PLAN (PO INDEX (INDX_PAON2))
 PLAN JOIN (P NATURAL, PT NATURAL)

 real	0m30.758s
 user	0m27.999s
 sys	0m2.611s

:=[ Ray

On Tue, 2010-09-07 at 22:17 +0000, Sean Leyne (JIRA) wrote:
> [ http://tracker.firebirdsql.org/browse/CORE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21684#action_21684 ] 
> 
> Sean Leyne commented on CORE-3127:
> ----------------------------------
> 
> What happens if you try:
> 
> SELECT 
>   p.first_name, p.last_name, pt.patient_id, pt.billto_id, pt.species_id, pt.color, pt.owner_label, pt.deact_code
> FROM patients pt, people p
> WHERE
>   pt.office_id = 1 
>   and pt.deact_code is null 
>   and pt.soundex_name like 'M24%'
>   and (
>     pt.billto_id = p.person_id 
>     or EXISTS (select 1 from patient_owners po where po.patient_id = pt.patient_id and po.person_id = pt.billto_id)
>   )
> ;
> 
> 
> > somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40
> > -------------------------------------------------------------------------------------------------------------------------------------
> >
> >                 Key: CORE-3127
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-3127
> >             Project: Firebird Core
> >          Issue Type: Bug
> >          Components: Engine
> >         Environment: Reproducible with isql - tested in 2.0.6 and 2.1.3 - on MAC, Linux and PC platforms
> >            Reporter: Ray Holme
> >         Attachments: addindex.ddl, out.txt, test_xx, vetAdmin.gbak.gz, vetAdmin.so
> >
> >
> > I have a DB, copy of the Linux UDF (can be eliminated as computed fields not referenced in query), copy of the query, timings under 2 releases of Linux (first seen on PC, then on MAC, but confirmed here on  Linux), and an add Index statement that works around the problem for us.
> 

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-3127) somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40

[Ray H. <rh...@ro...>]

Sean has no problem and neither did I - sorry.

ray@rainbow FB_bug]$ ls
addindex.ddl  out.txt  test_xx  vetAdmin.gbak.gz  vetAdmin.so
[ray@rainbow FB_bug]$ gunzip vetAdmin.gbak.gz 
[ray@rainbow FB_bug]$ gbak -rep -z vetAdmin.gbak test.fdb
gbak:gbak version LI-V2.0.5.13206 Firebird 2.0
gbak:    Version(s) for database "test.fdb"
	Firebird/linux AMD64 (access method), version "LI-V2.0.5.13206 Firebird
2.0"
	on disk structure version 11.0
[ray@rainbow FB_bug]$ ls -l
total 21308
-rw-r--r--. 1 ray staff      146 2010-09-07 17:33 addindex.ddl
-rw-r--r--. 1 ray staff     1077 2010-09-07 17:33 out.txt
-rw-rw----. 1 ray staff 16545792 2010-09-08 06:56 test.fdb
-rw-r--r--. 1 ray staff      513 2010-09-07 17:32 test_xx
-rw-r--r--. 1 ray staff  5242368 2010-09-07 17:33 vetAdmin.gbak
-rw-r--r--. 1 ray staff    14816 2010-09-07 17:33 vetAdmin.so




On Wed, 2010-09-08 at 03:28 +0000, Dmitry Yemanov (JIRA) wrote:
> [ http://tracker.firebirdsql.org/browse/CORE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21688#action_21688 ] 
> 
> Dmitry Yemanov commented on CORE-3127:
> --------------------------------------
> 
> The attached backup fails to restore with v2.0.5:
> 
> unsuccessful metadata update.
>      TABLE INVOICE_LINES.
>      Can't have relation with only computed fields or constraints.
> 
> 
> > somewhere after 2.0.5 - apparently 2.0.6 a significant change was made to the optimizer - I had a query that ran in 2 seconds take 40
> > -------------------------------------------------------------------------------------------------------------------------------------
> >
> >                 Key: CORE-3127
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-3127
> >             Project: Firebird Core
> >          Issue Type: Bug
> >          Components: Engine
> >         Environment: Reproducible with isql - tested in 2.0.6 and 2.1.3 - on MAC, Linux and PC platforms
> >            Reporter: Ray Holme
> >         Attachments: addindex.ddl, out.txt, test_xx, vetAdmin.gbak.gz, vetAdmin.so
> >
> >
> > I have a DB, copy of the Linux UDF (can be eliminated as computed fields not referenced in query), copy of the query, timings under 2 releases of Linux (first seen on PC, then on MAC, but confirmed here on  Linux), and an add Index statement that works around the problem for us.
> 

Re: [Firebird-test] -923 isc_attach_database: connection rejected by remote interface

[philippe m. <mak...@fi...>]

> The binary was compiled from the debian squeeze source package.
did you report this to Debian maintainer ?
can you try with snapshot build, or build you're self from the svn ?
https://firebird.svn.sourceforge.net/svnroot/firebird/firebird/branches/B2_5_Release

how many connection, how many transaction are involved ?

better re posting this to the devel list

Re: [Firebird-test] -923 isc_attach_database: connection rejected by remote interface

[Russell S. <rus...@st...>]

On Wed, 2010-09-01 at 13:09 +1000, Russell Stuart wrote:
> Using python's kinterbase to talk to the server I am getting this error:
> 
>   kinterbasdb.OperationalError: (-923, 'isc_attach_database: \n  connection rejected by remote interface')

I switched to the classic server.  It all went well for a few days, then
it hit what appears to be the same problem.

This time there was no problem connecting to the server, as you might
expect given the classic version was being used.  By every connection
had frozen, meaning it appeared the client was waiting for a response
from the server that never came.

I made a guess at the oldest fb_inet_server being the problem.  An lsof
of it showed it had a active connection to port 3050.  I killed the
process that held that connection open (an apache2 instance).  Then the
lsof showed the connection had gone to a CLOSE_WAIT state, but the
fb_inet_server didn't exit and all other fb_inet_server instances
remained frozen.  So then I killed it with SIGTERM.  No difference - it
didn't exit, and all other fb_inet_server's remained frozen.  So then I
reluctantly killed it with SIGKILL.  It died, and all other
fb_inet_server servers then unblocked and went on their merry way.

I looks to me like 2.5 has a locking problem - one that can take down
all instances of a classic server.   It smells like the same problem
that afflicted the super server, the only difference being that once the
super sever deadlocked it didn't do accept()'s to new connections so
they failed.

I can't reproduce this problem, but it does happen fairly regularly in
the super server (at least once per day).  I am willing to go to a bit
of effort to find it, if someone wants to tell me what to do.

[Firebird-test] -923 isc_attach_database: connection rejected by remote interface

[Russell S. <rus...@st...>]

Using python's kinterbase to talk to the server I am getting this error:

  kinterbasdb.OperationalError: (-923, 'isc_attach_database: \n  connection rejected by remote interface')

The server runs fine for after being started, then I will get a bunch of
those errors from several different applications, then it will come good
again for a while.  It appears that after 24 hours or so it gets to the
stage where it can't recover.

These messages are appearing in /var/log/firebird2.5.log:

        titan (Client)  Mon Aug 30 19:58:05 2010
                INET/inet_error: connect errno = 111

I am trying to figure out what might be causing this, but in the mean
time I will probably switch to the classic server.  Can anybody give me
some hints?  The server is regularly asked to do large transactions they
might take 30 to 40 seconds to complete.  Oddly, when I do an lsof on
fbserver when this is happening it typically has no client connections
open.

Database:	firebird2.5-super
Version:	2.5.0.26054 ReleaseCandidate3.ds2
OS:		Debian Sarge 32bit

The binary was compiled from the debian squeeze source package.

Re: [Firebird-test] [FB-Tracker] Commented: (CORE-1978) INSERT with multi-values

[Gustavo T. <gus...@gm...>]

Good night,

Bulk_insert by ISQL?, I use external table for masive load, is very
effective but need more code by to prepare the files and SP's for to process
the data, in other words I need a simple way for insert multiple values (500
or less rows).

I will like to hear your opinion/solutions.


Ing. Gustavo Torres

2010/8/3 Dimitry Sibiryakov (JIRA) <tr...@fi...>

>
>    [
> http://tracker.firebirdsql.org/browse/CORE-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21472#action_21472]
>
> Dimitry Sibiryakov commented on CORE-1978:
> ------------------------------------------
>
> In ISQL it is already implemented as bulk_insert. In DSQL it is less
> effective than array DML. What's the point?
>
> > INSERT with multi-values
> > ------------------------
> >
> >                 Key: CORE-1978
> >                 URL: http://tracker.firebirdsql.org/browse/CORE-1978
> >             Project: Firebird Core
> >          Issue Type: Improvement
> >          Components: Engine
> >         Environment: Software platform
> >            Reporter: Gustavo Torres
> >            Priority: Minor
> >
> > I suggeste include Insert multi-values
> > INSERT INTO Table (a, b, c)
> >  values(1, 2, 3),
> > (4, 5, 6)
> > for improvement performance insert
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>