On 21/08/15 20:40, James Starkey wrote:
> First question: On a scale from 1 (don't care, wouldn't use it) to 5 (I
> need it yesterday) how important to us is the ability to encrypt
> database files. Assume a bobust encryption scheme and a moderately
> civilized key management system. Please feel
James Starkey wrote:
> I'm curious about how important people consider on-disk
> encryption to be. I have two questions.
> First question: On a scale from 1 (don't care, wouldn't use
> it) to 5 (I need it yesterday) how important to us is the
> ability to encrypt database files. [...]
2
My first
CLONE -Trace: make list of tables which were involved in statistics ordered by
their names (alphabetical)
-
Key: CORE-4912
URL: http://tracker.firebirdsql.org/
Title: Re: [Firebird-devel] On-disk Encryption
I'm curious about how important people consider on-disk encryption to be. I have two questions.
First question: On a scale from 1 (don't care, wouldn't use it) to 5 (I need it yesterday) how important to us is the ability to encrypt database fi
First question: On a scale from 1 (don't care, wouldn't use it) to 5 (I need it
yesterday) how important to us is the ability to encrypt database files.
2
Second question: If you would consider in-disk database encryption, on a scale
of 1 to 5 how important is unattended startup, i.e. no huma
I'm curious about how important people consider on-disk encryption to be.
I have two questions.
First question: On a scale from 1 (don't care, wouldn't use it) to 5 (I
need it yesterday) how important to us is the ability to encrypt database
files. Assume a bobust encryption scheme and a moderate
>You must commit transaction before you can see new monitoring snapshot.
Yes, I know that.
--
Mgr. Jiří Činčura
Independent IT Specialist
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.n
> MON$ATTACHMENTS never returns stale data (provided you query it in a new
> transaction every time), unless you forced abnormal disconnection at the
Sure, it's always a new transaction.
> network layer and the server's TCP stack didn't yet discover the
> connection as lost. In this case Firebird
21.08.2015 13:05, Jiří Činčura wrote:
> Selecting from mon$attachments gets sometimes stale data even after few
> seconds.
You must commit transaction before you can see new monitoring snapshot.
--
WBR, SD.
--
Fi
Why not setup a dummy db with triggers on connect/disconnect? Whether they
update a count field or log the event - it should be fast enough for the
purpose.
2015-08-21 14:05 GMT+03:00 Jiří Činčura :
> Hi *,
>
> Is there a way to somewhat get a number of connections to given database
> that's alwa
21.08.2015 14:05, Jiří Činčura wrote:
>
> Is there a way to somewhat get a number of connections to given database
> that's always (or in some predefined interval, known in advance) up to date?
> Selecting from mon$attachments gets sometimes stale data even after few
> seconds. Maybe there's som
Hi *,
Is there a way to somewhat get a number of connections to given database that's
always (or in some predefined interval, known in advance) up to date? Selecting
from mon$attachments gets sometimes stale data even after few seconds. Maybe
there's some fixed interval I should wait - basicall
12 matches
Mail list logo
