On Sat, Nov 17, 2012 at 3:36 AM, Dmitry Yemanov firebi...@yandex.ru wrote:
gbak - fb_dump
nbackup - fb_backup
because IMO it better reflects their goals.
Gbak is not equivalent to the MySQL or Postgres dumps which produce a
series of insert statements that can be edited. From my
19.11.2012 19:54, Ann Harrison wrote:
On Sat, Nov 17, 2012 at 3:36 AM, Dmitry Yemanov firebi...@yandex.ru
mailto:firebi...@yandex.ru wrote:
gbak - fb_dump
nbackup - fb_backup
because IMO it better reflects their goals.
Gbak is not equivalent to the MySQL or Postgres dumps
On 11/19/12 20:22, Dimitry Sibiryakov wrote:
19.11.2012 16:54, Ann Harrison wrote:
Gbak is not equivalent to the MySQL or Postgres dumps which produce a series
of insert
statements that can be edited.
I wonder how they manage big BLOBs?
As far as I remember in hex, but you may try
Hex encoded - and with some engines, you can specify compressed (read
zlib) output.
I have seen multiple different implementations of the extract
including some that use multiple different files in sub-directories,
while others extract to xml.
It all depends upon the engine and the purpose of
On 11/19/12 20:45, Dimitry Sibiryakov wrote:
19.11.2012 17:41, Alex Peshkoff wrote:
As far as I remember in hex, but you may try yourself.
Thanks, I'm not so curious. And I didn't say big for nothing: I can't
imagine SQL
statement of size 3-4Gb.
In a time I've played with postgres 4Gb
19.11.2012 17:41, Alex Peshkoff wrote:
As far as I remember in hex, but you may try yourself.
Thanks, I'm not so curious. And I didn't say big for nothing: I can't
imagine
SQL statement of size 3-4Gb. Firebird statement is limited to 64k, there is no
way to put big BLOB into it.
19.11.2012 18:38, Leyne, Sean wrote:
But we could adopt an approach similar to IBExpert, which creates 2 files for
each dump; 1 SQL file and 1 file containing the blob contents.
And to open a door for problems like I forgot to copy one file from set,
what's now.
This is a road to hell.
On Mon, Nov 19, 2012 at 11:41 AM, Alex Peshkoff peshk...@mail.ru wrote:
What can be said for sure - a series of insert statements is definitely
not optimized for size, but certainly well compressable.
The more serious problem is that each insert statement has to be compiled
and optimized -
On Mon, Nov 19, 2012 at 11:51 AM, Dalton Calford
dalton.calf...@gmail.comwrote:
Most hex encoded dumps have special programs to load the data back
into the engine - I could not imagine anyone trying to use a straight
sql script to handle any large datasets.
I assure you that MySQL dump
Ann Harrison wrote:
Most hex encoded dumps have special programs to load the data back
into the engine - I could not imagine anyone trying to use a straight
sql script to handle any large datasets.
I assure you that MySQL dump produces a text file containing insert
statements.
On 19 November 2012 12:52, Ann Harrison a...@qbeast.net wrote:
I assure you that MySQL dump produces a text file containing insert
statements.
Best regards,
Ann
Oh, I believe you, as I have seen them/used them, but like I said, I
could not imagine anyone (implied 'reasonable') using them
Dmitry,
fb_backup, fb_security, fb_fixup, fb_stats and fb_precompile
I believe gpre stands for preprocess, not precompile.
Ok, fb_preprocess it is! ;-)
I realize that the names are longer than the original, but they are
much more meaningful
Speaking about meanings, I'd suggest
18.11.2012 18:31, Leyne, Sean wrote:
I am not sure that nbackup is the ideal backup that it could be.
But this is exactly what in other SQL servers (Oracle at least) is called
backup.
--
WBR, SD.
--
Monitor
Speaking about meanings, I'd suggest this change:
gbak - fb_dump
nbackup - fb_backup
because IMO it better reflects their goals.
Although I was the one who approached Nikolay about the ideas for
nbackup, and paid for the development, I am not sure that nbackup is the
ideal
Den 2012-11-18 19:04 skrev Leyne, Sean såhär:
Speaking about meanings, I'd suggest this change:
gbak - fb_dump
nbackup - fb_backup
because IMO it better reflects their goals.
Although I was the one who approached Nikolay about the ideas for
nbackup, and paid for the development, I am not
I was simply trying to say, that I even with my history with the utility, I
have a nagging feeling that nbackup could be better. So, I am not sure if
nbackup is worthy of the official blessing that fb_backup conveys.
I know that I had problems with Nbackup when I tried it with our
17.11.2012 13:54, Philippe Makowski wrote:
I guess it depends on the keyboard layout, too.
yes, and we have fb_lock_print, fb_inet_server, fbsvcmgr, fbtracemgr,
fb_config, fbguard
Just a note. There's no fb_inet_server or fb_smp_server anymore. I don't
know anything about fb_config, is it
On 11/19/12 11:04, Dmitry Yemanov wrote:
17.11.2012 13:54, Philippe Makowski wrote:
I guess it depends on the keyboard layout, too.
yes, and we have fb_lock_print, fb_inet_server, fbsvcmgr, fbtracemgr,
fb_config, fbguard
Just a note. There's no fb_inet_server or fb_smp_server anymore. I don't
On Saturday 17 Nov 2012 09:21:22 marius adrian popa wrote:
I agree on ubuntu i have isql-fb and is a lot faster to type than isql_fb
I guess it depends on the keyboard layout, too.
Most important is to have a common and consistent prefix, I think. Especially
in environments with tabbed
On 17-11-2012 00:34, Adriano dos Santos Fernandes wrote:
Why do use underlines when fb alone is a good prefix (that don't mess
with the next word)?
Agreed. A prefix is fine, but I don't think it needs a separator. If we
do want a separator, I have to say that I don't like an underline as a
On 16-11-2012 20:23, Philippe Makowski wrote:
Hi all,
we have some binaries that have conflict name with other products :
isql (UNIX-ODBC) and gstat (Ganglia)
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat,
16.11.2012 23:38, Leyne, Sean wrote:
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat, fb_nbackup, fb_qli, fb_pre,
fb_split,
fb_qli
Basically, I agree with a new (and consistent) prefix. Personally, I'd
rather prefer
Redirects and FAQs can be refreshed , Memory can be refreshed
Documentation can be updated , we can't live in the ib 1.0 - 4.0 era forever
symlinks can be created at install times for oldtimers
Times changed from the Vax years and people request up to date
documentation and majority use a gui
On 17-11-2012 09:47, marius adrian popa wrote:
Redirects and FAQs can be refreshed , Memory can be refreshed
Documentation can be updated , we can't live in the ib 1.0 - 4.0 era forever
symlinks can be created at install times for oldtimers
Times changed from the Vax years and people request
Dmitry Yemanov [2012-11-17 09:36] :
16.11.2012 23:38, Leyne, Sean wrote:
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat, fb_nbackup, fb_qli, fb_pre,
fb_split,
fb_qli
Basically, I agree with a new (and consistent)
17.11.2012 10:54, Philippe Makowski wrote:
fbsql conflict with others products
Not quite so. These other products have file extensions.
--
WBR, SD.
--
Monitor your physical, virtual and cloud infrastructure from
Mark Rotteveel wrote:
On 17-11-2012 09:47, marius adrian popa wrote:
Redirects and FAQs can be refreshed , Memory can be refreshed
Documentation can be updated , we can't live in the ib 1.0 - 4.0 era forever
symlinks can be created at install times for oldtimers
Times changed from the Vax
Dimitry Sibiryakov [2012-11-17 11:06] :
17.11.2012 10:54, Philippe Makowski wrote:
fbsql conflict with others products
Not quite so. These other products have file extensions.
yes you are right
--
Monitor your
I'd suggest that new tool names come with a new set of revised switches,
and that a compatibility layer be developed (tools with old names
switches that call the new ones).
Ciao
--
Nando Dessena
--
Monitor your
On 17-11-2012 09:52, Nando Dessena wrote:
I'd suggest that new tool names come with a new set of revised switches,
and that a compatibility layer be developed (tools with old names
switches that call the new ones).
I'm totally if favor of this and manifest it a long time ago when that
-=| Philippe Makowski, 17.11.2012 10:48:19 +0100 |=-
it could be then
fb-sql, fb-dump, fb-security, fb-fixup, fb-stat, fb-backup, fb-qli,
fb-preprocess, fb-split,
fb-qli
or
fb_sql, fb_dump, fb_security, fb_fixup, fb_stat, fb_backup, fb_qli,
fb_preprocess, fb_split, fb_qli
PS
Ted Miglautsch [2012-11-17 13:40] :
Instead of changing fb's command name maybe we should make them change
their command names. :)
no way, too late, and even worst, isql from Firebird is not isql from
Interbase for example
we have to change ours, like we changed from gsd32 to fbclient.
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat, fb_nbackup, fb_qli, fb_pre, fb_split,
fb_qli
I would suggest:
fb_backup, fb_security, fb_fixup, fb_stats and fb_precompile
I realize that the names are longer than
I agree with the longer names , is also better for readability and
firebird manual seo
On Fri, Nov 16, 2012 at 9:38 PM, Leyne, Sean s...@broadviewsoftware.com wrote:
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat,
On 16-11-2012 17:23, Philippe Makowski wrote:
Hi all,
we have some binaries that have conflict name with other products :
isql (UNIX-ODBC) and gstat (Ganglia)
may be Firebird 3 is the good time frame to rename our binaries ?
for example :
fb_sql, fb_bak, fb_sec, fb_fix, fb_stat,
Why not use underlines?
On 11/16/12 6:34 PM, Adriano dos Santos Fernandes wrote:
Why do use underlines when fb alone is a good prefix (that don't mess
with the next word)?
--
Monitor your physical, virtual and cloud
I like long names and do not like underlines. It's more faster to type
a name without underline.
2012/11/17 Doug Chamberlin chamberlin.d...@gmail.com:
Why not use underlines?
On 11/16/12 6:34 PM, Adriano dos Santos Fernandes wrote:
Why do use underlines when fb alone is a good prefix (that
I agree on ubuntu i have isql-fb and is a lot faster to type than isql_fb
On Sat, Nov 17, 2012 at 8:58 AM, Roman Simakov roman.sima...@gmail.com wrote:
I like long names and do not like underlines. It's more faster to type
a name without underline.
2012/11/17 Doug Chamberlin
38 matches
Mail list logo