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.
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, fb_nbackup, fb_qli, fb_pre,
fb_split, fb_qli
--
Philippe
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
39 matches
Mail list logo
