> I've been trying not to get involved in this question, but it's not working.
> Generating XML with printf's is not a really good idea. Build of tree of XML
> objects and serialize the sucker. Hand counting angle brackets if for the
> birds.
I didn’t look at the patch yet (now i did and se
11.11.2015 04:40, Adriano dos Santos Fernandes wrote:
> About the code style...
>
> You surely should not reinvent another style. It's very easy to see that
> things like
>
> else
> if (...)
>
> Is never used this way in Firebird code.
>
> Also, nobody write this kind of things "detailed_format==2
Huh? What are you blithering about? Is this about my paragraphing styke
30 years ago?
Get a life.
On Tuesday, November 10, 2015, Adriano dos Santos Fernandes <
adrian...@gmail.com> wrote:
> About the code style...
>
> You surely should not reinvent another style. It's very easy to see that
> t
I've been trying not to get involved in this question, but it's not working.
JSON and XML are both complex formats that require formal parsers. JSON
can use a built-in parse, but that doesn't mean that a parser isn't
required. And one may reasonable argue than XML is more regular than
JSON a
About the code style...
You surely should not reinvent another style. It's very easy to see that
things like
else
if (...)
Is never used this way in Firebird code.
Also, nobody write this kind of things "detailed_format==2" without spaces.
Just a observation of 2 seconds in your code.
Not of
Hi,
Just my 2 cents:
I can see the benefit of an XML output, but then i would not use underscores
inside the tags and params.
Also i would prefer using the base operation as tag and not everything
capsulated inside
Something like:
RDB$RELATIONS
RDB$REL
Hi,
i know that team is now very busy - today released RC1..
but i have 3 questions
1. I fix some output indentation and i have removed Index name quotation
and i put patch file on own server
http://itstop.pl/SVNFB/FB3.patch
but is this good code formating and conversion? (changes in
jrd/recsr
but if you append info to same log file then will be good to see also date
part. and as option why not let user decide? I like this feature in Interbase
then why not in Firebird?
regards,Karol Bieniaszewski
Oryginalna wiadomość
Od: Dmitry Yemanov
Data: 10.11.2015 18:2
> 10.11.2015 15:19, liviuslivius wrote:
>> and also on page 110:
>> "See also: Tracker ticket CORE-4919" - this tracker ticket have not
>> correlation with subject
>> I suppose that different number should be?
>> regards,
Wednesday, November 11, 2015, 2:34:20 AM, Vlad wrote:
>Looks like typo
10.11.2015 19:15, liviuslivius wrote:
> hi,
>
> for every line date time will be different.
Time portion will be mo-or-less different, but not a date portion.
> and this is very usefull. e.g. you run backup or restore every day and at
> some day you see that restoring some table take too much
10.11.2015 20:15, liviuslivius wrote:
>
> for every line date time will be different.
Date part will be the same, that was the Vlad's point. Redirect output
to gbak-DDMM.log and look inside the log for the timings.
Dmitry
---
hi,
for every line date time will be different.and this is very usefull. e.g. you
run backup or restore every day and at some day you see that restoring some
table take too much time compared to previous days. You need to know exact time
when this happened and then you can go into server e
optimizer suggestion
Key: CORE-5006
URL: http://tracker.firebirdsql.org/browse/CORE-5006
Project: Firebird Core
Issue Type: Improvement
Components: Engine
Affects Versions: 2.5.2 Update 1
Environme
GSTAT reports wrong values for some index attributes after DML with
long-key-indexed field fails with "Maximum index level reached"
---
Key: CORE-5005
Method to demand use out-of-process stadalone server ( or oppositely, embedded
engine) in DPB or connection string
--
Key: CORE-5004
URL: http://tracke
10.11.2015 15:19, liviuslivius wrote:
> Hi,
> I have read topic "Run-time Statistics in gbak Verbose Output"
> and i see that there is not possibility to output date-time like below?
> gbak: 2015-11-10 14:15:59.123
No. It have no sense (as for me) to include the same info (date) into e
Hi,
I have read topic "Run-time Statistics in gbak Verbose Output"
and i see that there is not possibility to output date-time like below?
gbak: 2015-11-10 14:15:59.123
and also on page 110:
"See also: Tracker ticket CORE-4919" - this tracker ticket have not correlation
with subje
On 11/10/2015 01:41 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Which code for establishing two connections is right?
>
> This one:
>
> IProvider* disp = master->getDispatcher();
> IAttachment* att1 = disp->attachDatabase(status, "DB1", 0, NULL);
> IAttachment* att2 = disp->attachDa
Hello, All.
Which code for establishing two connections is right?
This one:
IProvider* disp = master->getDispatcher();
IAttachment* att1 = disp->attachDatabase(status, "DB1", 0, NULL);
IAttachment* att2 = disp->attachDatabase(status, "DB2", 0, NULL);
Or this one:
IProvider* disp1 =
10.11.2015 11:39, Dimitry Sibiryakov wrote:
> 10.11.2015 10:31, Vlad Khorsun wrote:
>> b) questionable itself
>
> Ask DK for corruption statistics.
Good argument ! Note, it's up to you to proof your point :)
> If a page is corrupted, server may crash trying to parse it. To prevent
> t
Implement pre-ODS 12 provider
-
Key: CORE-5003
URL: http://tracker.firebirdsql.org/browse/CORE-5003
Project: Firebird Core
Issue Type: Improvement
Components: Engine
Affects Versions: 3.0 RC 1
10.11.2015 10:31, Vlad Khorsun wrote:
> b) questionable itself
Ask DK for corruption statistics.
If a page is corrupted, server may crash trying to parse it. To prevent that
you'll
have to put a lot of checks on every parsing step.
IMHO, it is simpler and faster to check integrity of wh
10.11.2015 10:28, Alex Peshkoff wrote:
> Agree, but it's not-related to the wrong/correct crypt key
IMHO, one solution solving several problems at once is better that separate
solutions
for every single problem.
--
WBR, SD.
---
10.11.2015 11:20, Dimitry Sibiryakov wrote:
> 10.11.2015 10:13, Alex Peshkoff wrote:
>> Does anybody see problems with suggested approach?
>
> It cannot detect partially written or physically corrupted page.
>
This task
a) have no relation with encryption
b) questionable itself
Regards,
Vl
On 11/10/2015 12:20 PM, Dimitry Sibiryakov wrote:
> 10.11.2015 10:13, Alex Peshkoff wrote:
>> Does anybody see problems with suggested approach?
> It cannot detect partially written or physically corrupted page.
>
Agree, but it's not-related to the wrong/correct crypt key
---
10.11.2015 9:57, Alex Peshkoff wrote:
> In that case encrypting something from page header seems to be bad idea.
For encryption algorithms that are vulnerable to known-plaintext attack -
yes.
Fortunately, AES is not one of them.
--
WBR, SD.
--
10.11.2015 10:13, Alex Peshkoff wrote:
> Does anybody see problems with suggested approach?
It cannot detect partially written or physically corrupted page.
--
WBR, SD.
--
Firebird-Devel mailing list, web interfac
On 11/09/2015 11:08 PM, Roman Simakov wrote:
> Key correctness can be checked by engine via crypto-plugin...
Does anybody see problems with suggested approach?
If not - I will add a ticket to the tracker for myself.
--
F
On 11/09/2015 08:05 PM, Dimitry Sibiryakov wrote:
> 09.11.2015 18:00, Jim Starkey wrote:
>> It matters because if every page is encrypted with the same key and
>> initial state, information can be learned by building a table of first
>> blocks. If two pages have the same encryption, then an attack
29 matches
Mail list logo