[firebird-support] Permission denied with qli and isql

[lyotchik]

I am trying to convert from IB 6 on Unix to FB 2.1 on Ubuntu Linux. I 
have used IB since version 3.1 on a variety of different platforms. 

>From what I understand this should be easy. However, I cannot even ready a 
>database using qli or isql using FB. The system is located in a secure 
>environment with absolutely no Internet access. There are several users on the 
>system and they all have a number of databases which they own. FB seems to 
>need a firebird user. I do not know why that users is required but it has been 
>created. Any attempt to restore a gbak using any user but root fails with 
>"Permission denied". The directory into which I tried to restore the database 
>has permission of 777. Anybody can do anything. I was able to restore a 
>database using something called flamerobin. But the user (who should also have 
>unlimited access to the database) cannot access it using gbak, qli or isql. It 
>does not seem to matter who owns the database file, the owner or firebird. It 
>also does not seem to matter what the permissions on the database are.

How can this ridiculous security (I our installation) be turned off so the 
normal Linux users can access their databases without permission problems? I 
would prefer not having everyone log into the system as root. 

Re: [firebird-support] Re: The worst day i can have with firebird

[Jesús García]

> Is this related to user-interaction, cause I'm curious on the frequency 
> the query needs to be executed?
> 
No, is a programmer error. Is a Web page that shows a master detail. There is a 
stored procedure that returns comments of the detail. Instead of loading all 
data once and painting the page, master and detail is loaded in one 
transaction, and when painting the detail grid in the page, for each row is 
opening a transaction, execute the query that returns the comments of all 
detail lines, and close the query and transaction.

There are details with 60 or 80 lines, what makes 60 or 80 transactions, 
because when painting the detail grid, the transaction/query loop is executed.

If there is 100 users viewing orders, that implies 100 + 60 *100 transactions, 
Instead of 100. This behaviour along the day can sum between 25 and 30 
transactions not needed.

As I said is a programmer error, and I hope when is solved the error will 
disappear.

Regards, jesus._,___

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

Re: [firebird-support] Re: The worst day i can have with firebird

[Thomas Steinmaurer]

>> The Trace API is an underestimated new feature in 2.5, but a godsend to
>> analyze such situations.
>>
> I must say I have used the lite version of your fbtracemanager tool.

Which is perfectly fine. ;-)

>> Sounds a bit like running the query in a transaction with auto commit
>> turned on. You might see COMMIT_RETAIN in the trace output for an
>> auto-committed transaction, as this usually is the default option in the
>> various access layers when using auto commit.
>>
>>
> The problem is that the query must be executed When master/detail data is 
> loaded, and is executed after and using transaction for each query.

Is this related to user-interaction, cause I'm curious on the frequency 
the query needs to be executed?

-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/


> Regards, jesus
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> 
>
> ++
>
> 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
>
>
>

Re: [firebird-support] Re: The worst day i can have with firebird

[Jesus Garcia]

> The Trace API is an underestimated new feature in 2.5, but a godsend to 
> analyze such situations.
> 
I must say I have used the lite version of your fbtracemanager tool.
> 
> Sounds a bit like running the query in a transaction with auto commit 
> turned on. You might see COMMIT_RETAIN in the trace output for an 
> auto-committed transaction, as this usually is the default option in the 
> various access layers when using auto commit.
> 
> 
The problem is that the query must be executed When master/detail data is 
loaded, and is executed after and using transaction for each query.

Regards, jesus
> 


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

Re: [firebird-support] Re: The worst day i can have with firebird

[Thomas Steinmaurer]

> That's really useful for us all and well explained. It also highlights
> the attention we need to pay to transactions.

Would a screencast/webcast on some practical tips and tricks on 
transactions be of value?

-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/


> Thanks Jesús.
> Alan
>
> Alan J Davies
> Aldis
>
> On 07/07/2012 15:09, Jesús García wrote:
>> El 07/07/2012, a las 15:23, Alan J Davies
>> > >  escribió:
>>   >
>>   >  If you've found the source, share it with us. Was it a major fault in
>>   >  Firebird, as you originally thought? Or an error in your, or your
>>   >  programmer's, logic?
>>   >  Alan
>>   >
>>   >  Alan J Davies
>>   >  Aldis
>>   >
>> The error was not in Firebird, was in our programmer logic. I have used
>> the trace manager (thanks to that utility) to see whats happening in the
>> backstage. I have seen that there is one query that is continuosly
>> executed, and for each execution opens a transaction.
>>
>> Is a web page that shows a master detail information. For each detail
>> row, once the master and detail records are loaded, opens a transaction
>> runs a query and close query and transaction.
>>
>> This morning, that is a day of not so much work, is around 1/6 of a
>> normal day, monitoring the server, the process opens 2.5
>> transactions/second and runs the query in each transaction and
>> sometimes, for one detail row, the transaction/query is executed 2 times.
>>
>> In a normal day, that process can be multiplied by 10 in peaks, that
>> implies 25 transactions/second plus the normal run of the user requests.
>>
>> May be Firebird is out of resources with the current configuration, and
>> that amount of work.
>>
>> In a first sight, i thought there was a problem with Firebird, because I
>> saw so much transactions increments (for example 2 transactions in
>> one minute), and i could not think that the source of the error was web
>> page problem. What also confused me was that there was transaction
>> numbers higher with timestamp lower than transactions with lower
>> transaction_id.
>>
>> The programmer error is there for months, but until 3 days ago Interbase
>> was running.
>>
>> I'm going to check others customers logs, to see if the error is
>> recorded, but all our customers, except this one and another, uses
>> superserver, and they have less loaded systems.
>>
>> Hope this will help someone, because I have seen threads in this list
>> talking about jumps in transactions ID.
>>
>> Jesus
>>
>>   >
>>
>> [Non-text portions of this message have been removed]
>>
>>
>
>
>
> 
>
> ++
>
> 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
>
>
>

Re: [firebird-support] Re: The worst day i can have with firebird

[Thomas Steinmaurer]

>> If you've found the source, share it with us. Was it a major fault in
>> Firebird, as you originally thought? Or an error in your, or your
>> programmer's, logic?
>> Alan
>>
>> Alan J Davies
>> Aldis
>>
> The error was not in Firebird, was in our programmer logic. I have used the 
> trace manager (thanks to that utility) to see whats happening in the 
> backstage. I have seen that there is one query that is continuosly executed, 
> and for each execution opens a transaction.

The Trace API is an underestimated new feature in 2.5, but a godsend to 
analyze such situations.

Sounds a bit like running the query in a transaction with auto commit 
turned on. You might see COMMIT_RETAIN in the trace output for an 
auto-committed transaction, as this usually is the default option in the 
various access layers when using auto commit.

Btw, if this is a very frequently executed query, you could try to run 
the transaction in READ COMMITTED and READ ONLY, which doesn't impact 
the server negatively, even if the transaction is running for a longer 
period.


-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/


> Is a web page that shows a master detail information. For each detail row, 
> once the master and detail records are loaded, opens a transaction runs a 
> query and close query and transaction.
>
> This morning, that is a day of not so much work, is around 1/6 of a normal 
> day, monitoring the server, the process opens 2.5 transactions/second and 
> runs the query in each transaction and sometimes, for one detail row, the 
> transaction/query is executed 2 times.
>
> In a normal day, that process can be multiplied by 10 in peaks, that implies 
> 25 transactions/second plus the normal run of the user requests.
>
> May be Firebird is out of resources with the current configuration, and that 
> amount of work.
>
> In a first sight, i thought there was a problem with Firebird, because I saw 
> so much transactions increments (for example 2 transactions in one 
> minute), and i could not think that the source of the error was web page 
> problem. What also confused me was that there was transaction numbers higher 
> with timestamp lower than transactions with lower  transaction_id.
>
> The programmer error is there for months, but until 3 days ago Interbase was 
> running.
>
> I'm going to check others customers logs, to see if the error is recorded, 
> but all our customers, except this one and another, uses superserver, and 
> they have less loaded systems.
>
> Hope this will help someone, because I have seen threads in this list talking 
> about jumps in transactions ID.
>
> Jesus
>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> 
>
> ++
>
> 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
>
>
>

Re: [firebird-support] Re: The worst day i can have with firebird

[Alan J Davies]

That's really useful for us all and well explained. It also highlights 
the attention we need to pay to transactions.
Thanks Jesús.
Alan

Alan J Davies
Aldis

On 07/07/2012 15:09, Jesús García wrote:
> El 07/07/2012, a las 15:23, Alan J Davies
>  > escribió:
>  >
>  > If you've found the source, share it with us. Was it a major fault in
>  > Firebird, as you originally thought? Or an error in your, or your
>  > programmer's, logic?
>  > Alan
>  >
>  > Alan J Davies
>  > Aldis
>  >
> The error was not in Firebird, was in our programmer logic. I have used
> the trace manager (thanks to that utility) to see whats happening in the
> backstage. I have seen that there is one query that is continuosly
> executed, and for each execution opens a transaction.
>
> Is a web page that shows a master detail information. For each detail
> row, once the master and detail records are loaded, opens a transaction
> runs a query and close query and transaction.
>
> This morning, that is a day of not so much work, is around 1/6 of a
> normal day, monitoring the server, the process opens 2.5
> transactions/second and runs the query in each transaction and
> sometimes, for one detail row, the transaction/query is executed 2 times.
>
> In a normal day, that process can be multiplied by 10 in peaks, that
> implies 25 transactions/second plus the normal run of the user requests.
>
> May be Firebird is out of resources with the current configuration, and
> that amount of work.
>
> In a first sight, i thought there was a problem with Firebird, because I
> saw so much transactions increments (for example 2 transactions in
> one minute), and i could not think that the source of the error was web
> page problem. What also confused me was that there was transaction
> numbers higher with timestamp lower than transactions with lower
> transaction_id.
>
> The programmer error is there for months, but until 3 days ago Interbase
> was running.
>
> I'm going to check others customers logs, to see if the error is
> recorded, but all our customers, except this one and another, uses
> superserver, and they have less loaded systems.
>
> Hope this will help someone, because I have seen threads in this list
> talking about jumps in transactions ID.
>
> Jesus
>
>  >
>
> [Non-text portions of this message have been removed]
>
> 

Re: [firebird-support] Re: The worst day i can have with firebird

[Jesús García]

El 07/07/2012, a las 15:23, Alan J Davies  
escribió:
> 
> If you've found the source, share it with us. Was it a major fault in 
> Firebird, as you originally thought? Or an error in your, or your 
> programmer's, logic?
> Alan
> 
> Alan J Davies
> Aldis
> 
The error was not in Firebird, was in our programmer logic. I have used the 
trace manager (thanks to that utility) to see whats happening in the backstage. 
I have seen that there is one query that is continuosly executed, and for each 
execution opens a transaction.

Is a web page that shows a master detail information. For each detail row, once 
the master and detail records are loaded, opens a transaction runs a query and 
close query and transaction.

This morning, that is a day of not so much work, is around 1/6 of a normal day, 
monitoring the server, the process opens 2.5 transactions/second and runs the 
query in each transaction and sometimes, for one detail row, the 
transaction/query is executed 2 times.

In a normal day, that process can be multiplied by 10 in peaks, that implies 25 
transactions/second plus the normal run of the user requests.

May be Firebird is out of resources with the current configuration, and that 
amount of work.

In a first sight, i thought there was a problem with Firebird, because I saw so 
much transactions increments (for example 2 transactions in one minute), 
and i could not think that the source of the error was web page problem. What 
also confused me was that there was transaction numbers higher with timestamp 
lower than transactions with lower  transaction_id.

The programmer error is there for months, but until 3 days ago Interbase was 
running.

I'm going to check others customers logs, to see if the error is recorded, but 
all our customers, except this one and another, uses superserver, and they have 
less loaded systems.

Hope this will help someone, because I have seen threads in this list talking 
about jumps in transactions ID.

Jesus

> 


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

Re: [firebird-support] Re: The worst day i can have with firebird

[Alan J Davies]

 > I have found the source of the "jumps", and I hope there is only one
 > source. Once fixed, I hope the errors will disappear.
 >
If you've found the source, share it with us. Was it a major fault in 
Firebird, as you originally thought? Or an error in your, or your 
programmer's, logic?
Alan

Alan J Davies
Aldis

On 07/07/2012 14:15, Jesús García wrote:
>
> El 07/07/2012, a las 14:37, "hvlad"  > escribió:
>  >
>  > > After that crash, I see in the log page 1296554, page type 4 lock
>  > > conversion denied (215), and don'n know what to do with this errors.
>  > >
>  > > Another problem is that transactions_id jumps, 2, and 3 in one
>  > > minute.
>  >
>  > This is your starting point - find why it "jumps", fix it and you'll
> never
>  > see "lock conversion denied" errors like above.
>  >
>  >
> I have found the source of the "jumps", and I hope there is only one
> source. Once fixed, I hope the errors will disappear.
>
> Do you recommend to increment the hashslots also?
>
> Regards, Jesús
>
> [Non-text portions of this message have been removed]
>
> 

Re: [firebird-support] Re: The worst day i can have with firebird

[Jesús García]

El 07/07/2012, a las 14:37, "hvlad"  escribió:
> 
> > After that crash, I see in the log page 1296554, page type 4 lock
> > conversion denied (215), and don'n know what to do with this errors.
> > 
> > Another problem is that transactions_id jumps, 2, and 3 in one
> > minute.
> 
> This is your starting point - find why it "jumps", fix it and you'll never
> see "lock conversion denied" errors like above.
> 
> 
I have found the source of the "jumps", and I hope there is only one source. 
Once fixed, I hope the errors will disappear.

Do you recommend to increment the hashslots also?

Regards, Jesús 

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

[firebird-support] Re: Firebird prevents system from booting - Email found in subject

[sboydlns]

--- In firebird-support@yahoogroups.com, "Leyne, Sean"  wrote:

>
> 
> The Guardian is not necessary for more recent Windows versions, due to 
> changes to the Services functionality which supports the automatic restart 
> (within 1 minute) of a service which has ended abended.
> 
> Therefore, the use of the Guardian is not recommended for Windows 7.
> 
> 
> Sean
>



I disabled the guardian, made the main Firebird service automatic and the 
problem persists.  The system refuses to boot until I disable Firebird totally. 
 I can start Firebird manually after the system is booted, no problem.

Any ideas?

[firebird-support] Re: The worst day i can have with firebird

[hvlad]

--- In firebird-support@yahoogroups.com, Jesus Garcia wrote:
>
> Two days ago, we moved from one server with interbase 2009 windows 2003 and
> 4 Gb RAM to Firebird 2.5.2 Superclassic, 16 Gb RAM
> The database is around 21 Gb, and yesterday seems all was running fine.
> 
> Today, i have checked Firebird.log and i have seen that there is an error
> of type
> 1296554 page type 4 lock denied (216), and page type 4 lock denied in
> another page, that are logged from .
> 
> viewing monitoring tables, i have seen on transaction  opened for 4 hours,
> and i have tried to delete de attachment. When i have deleted it, firebird
> has crashed and around 130 users has been dropped. After that in
> Firebird.log, i see no information about the crash, and i don't know what
> can happen, and what to do, and where look up for the reason of the problem.

  Tune OS to produce crash dumps. 

> After that crash, I see in the log page 1296554, page type 4 lock
> conversion denied (215), and don'n know what to do with this errors.
> 
> Another problem is that transactions_id jumps, 2, and 3 in one
> minute.

  This is your starting point - find why it "jumps", fix it and you'll never
see "lock conversion denied" errors like above.

Regards,
Vlad