Re: [firebird-support] Re: Database file modified shortly after NBACKUP -L

[Kjell Rilbe kjell.ri...@marknadsinformation.se [firebird-support]]

den 2018-04-05 09:13, skrev hv...@users.sourceforge.net [firebird-support]:
>
> ---In firebird-support@yahoogroups.com,  wrote :
>
> ...
> >
> > It seems like the original database file is touched about a half to one
> > minute after being locked with NBACKUP -L.
> >
> > Why is the locked database file touched?
> >
> > I'm not sure if it's actually modified, but the timestamp is 
> certainly updated.
>
>   Firebird itself doesn't update file timestamp directly.
> But filesystem often does it in lazy\background mode (for performance 
> reason).
>
>   You may know for sure using ProcessMonitor tool, if you wish

Oh, Sorry Vlad, I didn't see your reply at first. My message thread view 
was apparentl corrupt in my e-mail client. Fixed that now.

Sounds like a reasonable explanation. I've inserted a five minute delay 
between lock and copy, but last night's run failed anyway. Guess I'll 
have to investigate a bit more. Thanks for the suggestion with procmon.

Regards,
Kjell

Re: [firebird-support] Database file modified shortly after NBACKUP -L

[Kjell Rilbe kjell.ri...@marknadsinformation.se [firebird-support]]

No clues?

Repeating the question in short form:
Why would it be that the database file is being touched about ½-1 minute 
AFTER being locked with NBACKUP -L?

I can see the timestamp of the file being updated.

Regards,
Kjell
-- 

Kjell Rilbe
Telefon: 0733-44 24 64
Marknadsinformation i Sverige AB
Ulvsundavägen 106C
168 67 Bromma
www.marknadsinformation.se 
08-514 905 90

den 2018-04-05 09:03, skrev Kjell Rilbe 
kjell.ri...@marknadsinformation.se [firebird-support]:
>
> Hi,
>
> I've been using FastCopy to make backup copies of a ~180 Gbyte Firebird
> database, under NBACKUP-L state.
>
> This has been working fine for years with Firebird 2.5 and an older
> version of FastCopy.
>
> After migrating the database to a new server and upgrading Firebird to
> 3.0 and FastCopy to latest version 3.41, I'm experiencing a problem that
> I find a bit strange.
>
> The backup script does this:
> 1. NBACKUP -L
> 2. FastCopy.
> 3. NBACKUP -N on original database file.
> 4. NBACKUP -F on copy.
>
> What happens is that FastCopy detects that the source file is modified
> during the copy operation and bails out.
>
> It seems like the original database file is touched about a half to one
> minute after being locked with NBACKUP -L.
>
> Why is the locked database file touched?
>
> I'm not sure if it's actually modified, but the timestamp is certainly
> updated.
>
> I am also not sure if this is new for Firebird 3, or if it happened with
> 2.5 too, but the old version of FastCopy failed to do the modification
> check.
>
> Regards,
> Kjell
> -- 
>
> Marknadsinformation logotyp
>
> Kjell Rilbe
> Telefon: 0733-44 24 64
>
> Marknadsinformation i Sverige AB
> Ulvsundavägen 106C
> 168 67 Bromma
> www.marknadsinformation.se 
> 08-514 905 90
>
> Företagskontakt.se 
> Personkontakt.se 
>
> 

[firebird-support] Re: no permission for INSERT access to TABLE PLG$SRP_VIEW

[todd.brass...@gmail.com [firebird-support]]

Now that we have granted the RDB$ADMIN ROLE in our actual database (not just 
SECURITY3.FDB) it seems to be working. 

 I thought for Firebird 3, sysdba can connect to the security database.
 

 Todd

[firebird-support] Re: Database file modified shortly after NBACKUP -L

[hv...@users.sourceforge.net [firebird-support]]

---In firebird-support@yahoogroups.com,  wrote :
 ...
 >
> It seems like the original database file is touched about a half to one 
> minute after being locked with NBACKUP -L.
 > 
> Why is the locked database file touched?
 > 
> I'm not sure if it's actually modified, but the timestamp is certainly 
> updated.
 
  Firebird itself doesn't update file timestamp directly. 
But filesystem often does it in lazy\background mode (for performance reason).

  You may know for sure using ProcessMonitor tool, if you wish

Regards,
Vlad

  

[firebird-support] Re: nbackup - Problem on "attach database"

[hv...@users.sourceforge.net [firebird-support]]

---In firebird-support@yahoogroups.com,  wrote :
 
  > When I try to make a backup with nbackup on our customer’s system (Windows 
Server 2016 – Firebird 3.0.3) we get the following message, while we are 
connected to the database with the “IBExpert” at the same time. When we are not 
connected, the backup will run.

What kind of connection is used in IBE ? I guess, it is embedded connection 
(local, default) - correct ?

Regards,
Vlad

Re: [firebird-support] no permission for INSERT access to TABLE PLG$SRP_VIEW

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Hello Todd,

Todd Brasseur wrote:

> Having Issues with 'create user' with Firebird 3.0

> It works fine on one computer where we are testing but not the other. 
> We think we did the same thing on both computers.

> Installed Firebird

> Created SYSDBA Account

> Created PRIVATEADMIN Account

> Granted Role RDB$ADMIN to PRIVATEADMIN (in security3.fdb)

> Log into our database as PRIVATEADMIN with ROLE RDB$ADMIN. Where 
> committing the Create User command, I get the error in the subject line

> no permission for INSERT access to TABLE PLG$SRP_VIEW

> The other computer adds the user without a problem.

Don't know why it does.

> What am I doing wrong?

>From the Language Reference:

Granting the RDB$ADMIN Role in the Security Database

Since nobody—not even SYSDBA— can connect to the security database,
the GRANT and REVOKE statements are of no use for this task. Instead,
the RDB$ADMIN role is granted and revoked using the SQL statements for
user management:

CREATE USER new_user
PASSWORD 'password'
GRANT ADMIN ROLE

or

ALTER USER existing_user
GRANT ADMIN ROLE

ALTER USER existing_user
REVOKE ADMIN ROLE
  

Note

GRANT ADMIN ROLE and REVOKE ADMIN ROLE are not statements in the GRANT
and REVOKE lexicon. They are three-word parameters to the statements
CREATE USER and ALTER USER.

HB

[firebird-support] Database file modified shortly after NBACKUP -L

[Kjell Rilbe kjell.ri...@marknadsinformation.se [firebird-support]]

Hi,

I've been using FastCopy to make backup copies of a ~180 Gbyte Firebird 
database, under NBACKUP-L state.

This has been working fine for years with Firebird 2.5 and an older 
version of FastCopy.

After migrating the database to a new server and upgrading Firebird to 
3.0 and FastCopy to latest version 3.41, I'm experiencing a problem that 
I find a bit strange.

The backup script does this:
1. NBACKUP -L
2. FastCopy.
3. NBACKUP -N on original database file.
4. NBACKUP -F on copy.

What happens is that FastCopy detects that the source file is modified 
during the copy operation and bails out.

It seems like the original database file is touched about a half to one 
minute after being locked with NBACKUP -L.

Why is the locked database file touched?

I'm not sure if it's actually modified, but the timestamp is certainly 
updated.

I am also not sure if this is new for Firebird 3, or if it happened with 
2.5 too, but the old version of FastCopy failed to do the modification 
check.

Regards,
Kjell
-- 

Marknadsinformation logotyp

Kjell Rilbe
Telefon: 0733-44 24 64

Marknadsinformation i Sverige AB
Ulvsundavägen 106C
168 67 Bromma
www.marknadsinformation.se 
08-514 905 90

Företagskontakt.se 
Personkontakt.se