Flash Filer
Mark
fast? Is it stable? Any significant gotchas? I've read all of the
promotional stuffy, now I'd like to hear from anyone that has used it. I
know this may be a database question, but none of the db groups seemed just
right for this question.
Thanks, Mark
Tim Sullivan
myself (they don't have a trial version). TurboPower is a great company, and
they have great products.
You may want to consider other database engines as well, however. Take a
look at Advantage (http://www.advantagedatabase.com). It provides similar
rich data types to FlashFiler and Paradox, as well as the performance of
Client/Server. It's inexpensive, fast, and well supported. And the local
server version is free! For more info you can hit their web site. You can
also check out their newsgroups at news://solutions.advantagedatabase.com
...
--
Tim Sullivan
Unlimited Intelligence Limited
Dimethylaminoethanol for your software
http://www.uil.net
"Mark" <mkn...@mgh.org> wrote in message news:39a2b3e9_1@dnews...
David Marcus
> What's the skinny on TurboPower's FlashFiler? Does it work?
Yes.
> Is it stable?
Yes.
> Any significant gotchas?
No SQL until the next version.
The FlashFiler newsgroup at news.turbopower.com is a good place to ask
questions. Lots of users over there will be happy to fill you in.
--
David Marcus
Huhtaman
Peck
I particularly like DBISAM... Eric and Tim are giving almost
around-the-clock
technical support!
--
Best regards,
Peck Kim Han
Ole Willy Tuv
If you want a low-cost, embedded DB engine with SQL capabilities, I
recommend you have a look at DBISAM V2 from http://www.elevatesoft.com
- Compiles into the exe with a small footprint
- No additional deployment
- Table and Query TDataset descendants
- Feature rich SQL
- The fastest engine around
- Excellent support
Best regards
Ole Willy Tuv
Grzegorz Wiktorowski
*very* stable. Communication layer is TCP/IP, IPX/SPX or even NETBEUI.
I've used on different platforms: Win9x, NT nad Citrix MetaFrame for over 2
years. Easy to configure. Full source published. Excellent support from
FlashFiler's developers as well as from TPXs.
Check turbopower.public.support.flashfiler.
-----
Grzegorz Wiktorowski
OiOK
Jerry Hayes
A database format is pretty damn important, I think you need to give us a
better needs requirement first. Without it, you're leaving your needs
assessment to the imagination of the community ;)
If it's for a single user app I'd definitely go DBISAM.
Do your users need to do any queries through other reporting tools? You
might want to look at something more standard.
IMHO, FlashFiler's niche is client/server communication for the purpose of
stability of the underlying data. It's not tremendously fast and there's no
SQL, but there's no seat licensing either ;)
Gotchas? Well, less than most proprietary data formats because you get the
source code. Utilities that ship with package are VERY bare-bones, but you
can always write your own. We had a nightmare with a version shipped before
it was ready, but I think that MOST of the problems have been fixed with
1.56. I'm hoping 1.57 will get rid of the rest of our nit-picky issues when
it ships.
VERY easy to deploy, literally copy the files somewhere else and a few
settings on the server.
Paul Motyer
> If it's for a single user app I'd definitely go DBISAM.
Why? Because of speed? or data reliabilty? or ...
IMHO, FF is more reliable; re: speed, see below.
> IMHO, FlashFiler's niche is client/server communication
> for the purpose of stability of the underlying data.
> It's not tremendously fast and there's no
> SQL, but there's no seat licensing either ;)
I guess you don't like to use my free FF SingleEXE enhancements then -
which makes FF go as fast as Paradox/BDE with LocalShare false.
SQL is the main issue. It's been promised for FF2 which is
due for release this year.
--
Paul Motyer
Mike Orriss (TeamB)
> I guess you don't like to use my free FF SingleEXE enhancements then -
> which makes FF go as fast as Paradox/BDE with LocalShare false.
>
DBISAM V2 is much, much faster than Paradox.
Mike Orriss (TeamB & Developer Express)
(Unless stated otherwise, my replies relate to Delphi 5)
(No unsolicited e-mail replies please)
Bruce McGee
Since you ask...
I am finding DBISAM to be very reliable and fast, especially in the
latest version. I use it everywhere I would have used Paradox tables
before, both single and multi user. In fact, I use it in any software
that doesn't have to talk to our corporate database. The one exception
is where we require lightweight clients with real client/server
functionality, and we intend to use Interbase. What can I say; I'm a
sucker for a bargain <g>.
The biggest thing that drew me to DBISAM would have to be SQL support.
The latest version now has sub selects and lets me create/drop tables
using SQL (everyone maintains their tables using SQL script, right?).
Without trying to sound like a fanatic, we are very happy with it so
far.
I haven't used Flash Filer, so I can't comment on how it compares. Is
anyone using both?
Regards,
Bruce McGee
Paul Motyer wrote:
>
> "Jerry Hayes" wrote
>
> > If it's for a single user app I'd definitely go DBISAM.
>
> Why? Because of speed? or data reliabilty? or ...
> IMHO, FF is more reliable; re: speed, see below.
>
> > IMHO, FlashFiler's niche is client/server communication
> > for the purpose of stability of the underlying data.
> > It's not tremendously fast and there's no
> > SQL, but there's no seat licensing either ;)
>
> I guess you don't like to use my free FF SingleEXE enhancements then -
> which makes FF go as fast as Paradox/BDE with LocalShare false.
>
Jerry Hayes
"Paul Motyer" <s...@the.sig.com> wrote in message news:39a6057e$1_2@dnews...
> "Jerry Hayes" wrote
>
> > If it's for a single user app I'd definitely go DBISAM.
>
> Why? Because of speed? or data reliabilty? or ...
> IMHO, FF is more reliable; re: speed, see below.
[Prior message stuff snipped]
> I guess you don't like to use my free FF SingleEXE enhancements then -
> which makes FF go as fast as Paradox/BDE with LocalShare false.
>
> SQL is the main issue. It's been promised for FF2 which is
> due for release this year.
My initial reason for recommending DBISAM for single user is the problems
that I've had with the FF client code base. We bought FF with version 1.54
last year, which had a great deal of problems for us. Things are much, much
better with 1.56, and I'm looking forward to 1.57. I also think that
there's a steeper learning code for using FF in single user than DBISAM.
If DBISAM and FF with an add on were equally speed compatible, and speed was
the main reason, then I'd still go with DBISAM out of the box, (I don't
know the performance numbers here).
FF has a lot of merit and can be used to make a very good single user app.
It's just not the primary focus of the FF product. The user may have some
specific series of needs that makes a single user FF app the best choice, I
just don't know.
Which brings me back to what I intended as the initial point of my post -- I
hope that the originator reposts and specifies what his needs are! If a
main requirement is user queries through other software, the best solution
may be Access tables via ODBC Express. All of this single user discussion
may be moot because he's looking for a networked database ;)
Tim Young
Set RequestLive to True for the query and you won't have nearly as much
contention and the performance will improve.
--
Tim Young
Elevate Software
www.elevatesoft.com
Be sure to check out our new support
newsgroups at news://news.elevatesoft.com
Bruce Roberts
"Paul Motyer" <s...@the.sig.com> wrote in message news:39a689ae_1@dnews...
> "Mike Orriss (TeamB)"
>
> > > which makes FF go as fast as Paradox/BDE with LocalShare false.
>
>
>
> A FF SingleEXE (Client and Server in the same App),
> with my FF SingleEXE enhancements,
> took 1128.102 sec [18 min, 48.102 sec] to create a table with
> 2 fields and 2 indices on a Pentium III, 450, NT 4, D4.03
> and add 1 million records.
>
> How long would DBISAM take?
There was a thread in the DBISAM SQL NG that involved a test of record
insertion. As I recall, the user reported an insertion rate of 1200 rec/sec
(about 30% faster than your test). But one should always be careful with
test results, every ones needs are different. Elevate has posted extensive
test results and comparisons at www.elevatesoft.com.
Mark
to fairly complex multi-user apps ranging from 5 to 50 concurrent users.
These are primarily medical-research related applications, and they
generally see a lot of use, although typically not a lot of records are
added during a given day(dozens or hundreds per day, rather than thousands
or more). I have used Paradox tables, almost exclusively, with very little
trouble, but distribution and configuration of the BDE is always
problematic, and I'm always waiting for the gotchas I'm always hearing about
with Pdox tables. Further, I would like to use one DB platform if possible
for both single and multi-user C/S apps, simply to minimize the number of
learning curves I must climb. In the fairly short term, many of my users
will need IP access to this data, so I need something that will work
properly over IP. How do FF and DBISAM compare in this regard? How about
security? Do either of these create a db object that hides the db
tables/files from simple file system browsing? Raw speed is important, but
stability and security are more critical to my bread and butter.
Thanks for all of the comments to this point. Mark.
Jerry Hayes <jhayes at medware-inc dot com> wrote in message
news:39a6869d$1_2@dnews...
>
> "Paul Motyer" <s...@the.sig.com> wrote in message
news:39a6057e$1_2@dnews...
> > "Jerry Hayes" wrote
> >
> > > If it's for a single user app I'd definitely go DBISAM.
> >
> > Why? Because of speed? or data reliabilty? or ...
> > IMHO, FF is more reliable; re: speed, see below.
>
> [Prior message stuff snipped]
> > I guess you don't like to use my free FF SingleEXE enhancements then -
> > which makes FF go as fast as Paradox/BDE with LocalShare false.
> >
Bruce McGee
I can't say I duplicated your test exactly. In fact, I haven't done any
formal speed benchmarks aside from testing queries in my software.
However, we do have 4 applications with multiple users sharing DBISAM
files over our network, and I have not had any of the speed problems you
describe.
There is an application installed on our network for use across the
company. It gets fairly consistent usage with between 3 and 5 users at
a given time and more toward the middle of the month (cut off for this
process). There are lots of inserts and updates, and to date we haven't
had a significant speed issue (network not withstanding).
The program fetches all rows anyway. This is between 50 and 250,
filtered for the specific user and their selection. I try not to bring
down 10,000 rows across the network if I can avoid it.
Maybe Tim or Eryk can include some benchmarks that include concurrent
usage.
Regards,
Bruce McGee
Jimmy Harlindong wrote:
>
> Bruce,
>
> I did some tests with DBISAM, one program is appending data in a timer. The
> timer event loops to add 500 records on one time event.
>
> The program works fine and the loop works FAST. That is true.
>
> Then I stopped the program.
>
> Then I ran DBSYS and tried to run
> SELECT * FROM THESAMETABLE
>
> It also went FAST.
>
> Now, I ran the looping program again, and left it running while I switch to
> DBSYS
> and ran SELECT * FROMTHESAMETABLE
>
> since the loop has been adding about 10000 records, DBSYS goes to a complete
> CRAWL
>
> Now talk about multiuser ? With lots of people trying to do SELECT query ?
> hrmm... I DOUBT this.
>
> now I created an EXACTLY the same program now using IBX.
>
> Instead of DBSYS I used EMS's QuickDesk, and ran the same Query. After
> running the query I hit "Goto Last Record" button on the nav button, so it
> will fetch all.
>
> There is not much performance impact that the other program (that is doing
> the looping) do to the SELECT query done by QuickDesk.
>
> For the record, the loop commits transaction everytime it posts, not outside
> of the loop.
>
> It appears that SELECT * in DBSYS / DBISAM will fetch all, whereas in
> QuickDesk (or IBX too perhaps) will fetch all only when I go to last record.
>
> I am wondering what experience / tests have you done.... I know mine is so
> simple but it should represent the RAW MEAT of the underlying database.
>
> Cheers,
> Jimmy
Ole Willy Tuv
I just tested DBISAM 2.03 myself.
I append 200000 records with 10 fields in 2.75 minutes, that's 1200 records
per second.
Opening the 200000 records dataset is 20 ms.
Looping through the entire result set is 15 seconds in the first iteration,
6 seconds in the next.
I can't see where you possible could find better speed elsewhere.
Regards
Ole Willy Tuv
Brion L. Webster
the access over IP (not free). It certainly makes things easier for distributed
data access.
-Brion
Jimmy Harlindong
It also went FAST.
Cheers,
Jimmy
"Bruce McGee" <bmc...@ionline.net> wrote in message
news:39A6625E...@ionline.net...
Paul Motyer
> > which makes FF go as fast as Paradox/BDE with LocalShare false.
> DBISAM V2 is much, much faster than Paradox.
Just how fast is it?
A FF SingleEXE (Client and Server in the same App),
with my FF SingleEXE enhancements,
took 1128.102 sec [18 min, 48.102 sec] to create a table with
2 fields and 2 indices on a Pentium III, 450, NT 4, D4.03
and add 1 million records.
How long would DBISAM take?
Here's the FF code:
uses DB, FFDB, FFCLIntf;
{$R *.DFM}
function RandomStr(Sz: integer): string;
var j: integer;
begin
SetLength(result, Sz);
for j:= 1 to Sz do result[j]:= chr(65+random(26));
end;
procedure TForm1.Button1Click(Sender: TObject);
var i, TransCount: integer;
StartTime: DWORD;
Table: TffTable;
const MaxTransactions = 50000;
begin
Button1.enabled:= false;
StartTime:= GetTickCount;
// setup an alias
Table:= TffTable.create(nil);
try FFDbiDeleteAlias(Session.handle, 'TEST');
FFDbiAddAlias(Session.handle, 'TEST',
ExtractFilePath(Application.exename));
// Create a Table
with Table do
begin
DatabaseName:= 'TEST';
TableName:= 'ABC';
with FieldDefs do
begin
Clear;
Add('Field1', ftInteger, 0, False);
Add('Field2', ftString, 30, False);
end;
with IndexDefs do
begin
Clear;
Add('$FFPRIM', 'Field1', [ixUnique]);
Add('Fld2Indx', 'Field2', [ixCaseInsensitive]);
end;
CreateTable;
open;
// Add records
TransCount:= 0;
for i:= 1 to 1000000 do
begin
if TransCount=0 then Database.StartTransaction;
insert;
Fields[0].AsInteger:= i;
Fields[1].AsString:= RandomStr(30);
post;
inc(TransCount);
if (i mod 100)=0 then
begin
label1.caption:= inttostr(i)+' of 1,000,000';
Application.ProcessMessages;
end;
if TransCount=MaxTransactions then
begin
Database.Commit;
TransCount:= 0;
end;
end;
if Database.InTransaction then Database.Commit;
end;
finally Table.free; end;
ShowMessage(IntToStr(GetTickCount-StartTime)+' msec');
end;
--
Paul Motyer
Jimmy Harlindong
Sounds to me that you could use Interbase 6 + IBX
"Mark" <mkn...@mgh.org> wrote in message news:39a6c443$1_1@dnews...
Jimmy Harlindong
e.g. "64.1.2.3:c:\database\mydiary.gdb" ?
ASTA is very nice *but* it's not royalty free (afaik). However seeing that
IB6 client only needs gds32.dll (from what I've been told) which is less
than 500K it doesn't make too bad of an "ASTA" alternative :) what do you
think?
Can anyone comment / clarify this please?
"Brion L. Webster" <brion....@nospam.ci.fresno.ca.us> wrote in message
news:8o6skg$h3...@bornews.borland.com...
Paul Motyer
> I append 200000 records with 10 fields in 2.75 minutes, that's 1200
records
> per second.
> Opening the 200000 records dataset is 20 ms.
> Looping through the entire result set is 15 seconds in the first
iteration,
> 6 seconds in the next.
>
> I can't see where you possible could find better speed elsewhere.
That's a bold statement! Even Paradox/BDE, local share false can beat that.
Why not run the code I posted - with 2 indices and 1 million
inserts - and tell us the times? Or, give us your code so I can
run it and post the FF times?
Appending *without indices* is always fast.
When using indices, 200,000 v 1,000,000 is a HUGE difference
because adding the 1st 1000 records and the last 1000 records
are totally different in timing.
For example, changing the code I posted slightly
(200,000 records, no indices, one transaction):
gives 19.8 sec total, 10,081 records per sec
or for 1 million records: gives 111.19 sec, 8994 records per sec
If you look at the code, it's pretty simple stuff.
Regarding the difficulties creating a SingleEXE v a SeparateEXE:
To make the App a Client & Server in the one App
involves setting one Compiler define.
To make it a Client App accessing an external Server
involves un-setting the same Compiler define.
It's hardly difficult.
So, the point is FF is simple, very reliable and, for
Client & Server in the one App, can be really fast.
I guess it may sound like I'm advertizing. I'd call it
just giving an alternate view.
Look at the Subject line. Most of the responders just
chant the DBISAM mantra. It does annoy me that so
many evangelize DBISAM and make claims about
Flash Filer that I consider mis-leading.
I'd like to make it clear that I'm a
Turbopower customer only and have never received
any payments or freebies from them.
--
Paul Motyer
Mike Orriss (TeamB)
> Look at the Subject line. Most of the responders just
> chant the DBISAM mantra. It does annoy me that so
> many evangelize DBISAM and make claims about
> Flash Filer that I consider mis-leading.
>
From where I'm sitting it looks like you are tarred with the other brush
<g>
I own both products but must admit that I have never deployed anything
using FF (I probably bought the product far too early and never got to
grips with it). In the meantime, DBISAM provided SQL support and so I
don't even consider FF for new apps.
Ole Willy Tuv
> When using indices, 200,000 v 1,000,000 is a HUGE difference
> because adding the 1st 1000 records and the last 1000 records
> are totally different in timing.
Not with DBISAM.
My test table is 10 fields with one primary index.
I've run my test project with DBISAM, ASA7/NativeDB and ALS as back-ends.
I've mailed you the source for the test project which you can modify to FF.
Could be interesting to see your timings with FF.
Regards
Ole Willy Tuv
Ole Willy Tuv
Paul Motyer
paulmotyer at usa dot net
--
Paul Motyer
Paul Motyer
> In article <39a71942_1@dnews>, Paul Motyer wrote:
> > Look at the Subject line. Most of the responders just
> > chant the DBISAM mantra. It does annoy me that so
> > many evangelize DBISAM and make claims about
> > Flash Filer that I consider mis-leading.
> From where I'm sitting it looks like you are tarred with the other brush
> <g>
I think you're drawing a rather long bow.
The original post asked about FF, and the answer is FF would work
just fine unless he requires SQL
The original poster's 2nd post asks about FF v DBISAM and IP.
I don't know so much about DBISAM.
Maybe things have changed but last I looked
- you don't get the core source code so you cannot alter
it nor fix any bugs - but you can report them and they are
usually acted on quickly
- it's a shared file database
- 50 concurrent users? Someone else may know
- DBISAM is being actively developed (by a team of two)
- there is an active and helpful newsgroup
For FF:
- FF includes FULL source code.
- FF is Client Server which is inherently more robust
- FF definately will work with 50 concurrent users - and many more.
- FF is being actively developed (by a team of 3 or 4)
- FF also works fine (in fact, best) using IP - internet connections
work just fine.
- there is an active and helpful newsgroup and because the full
source code is available there are many people who can answer
the technical/hard questions
Mark, whilst DBISAM is more actively promoted in these NGs,
I suspect either would serve your needs.
--
Paul Motyer
Ole Willy Tuv
----- The following addresses had permanent fatal errors -----
> paulmotyer at usa dot net
Please send me a personal e-mail I can respond to.
Ole Willy Tuv
Paul Motyer
sure.
--
Paul Motyer
Tim Young
<< - you don't get the core source code so you cannot alter it nor fix any
bugs - but you can report them and they are usually acted on quickly >>
Just so you know, full source code has been an option since June when we
shipped version 2.0. Also, we now ship the source code to all of the
utilities with every version, even the trial versions.
Ole Willy Tuv
Since TurboPower doesn't publish a trial version of FF, I downloaded their
demo application out of curiosity.
Luckily, I was able to create the table structure and import the 200000
records from an ASCII fixed file.
I did not time it, but appending the 200000 records to the FF table took
some 15-20 minutes or so, in any case much longer than the 2.75 minutes with
DBISAM 2.03 on my Windows 98 system.
Regards
Ole Willy Tuv
> > I append 200000 records with 10 fields in 2.75 minutes, that's 1200
> records
> > per second.
> That's a bold statement! Even Paradox/BDE, local share false can beat
that.
Ole Willy Tuv
I can confirm that the append test flies even faster on my system,
200000 records appended in 37 seconds here.
However, to make a realistic comparison, could you make an exact multi-user
clone of my test project with FF as back-end, using transactions which is
what I've been testing for.
Ole
> Please note that this is a Single User App - not multi-user.
> Multi-User FF Apps are not this fast.
Bruce Roberts
"Paul Motyer" <s...@the.sig.com> wrote in message news:39a79ebb_1@dnews...
> "Mike Orriss (TeamB)" wrote
> - FF is being actively developed (by a team of 3 or 4)
This must be a new development. One of the consistent NG complaints about FF
in the past has been that TP has not been doing anything with the product.
Grzegorz Wiktorowski
>I own both products but must admit that I have never deployed anything
>using FF (I probably bought the product far too early and never got to
>grips with it). In the meantime, DBISAM provided SQL support and so I
>don't even consider FF for new apps.
simple SELECT).
-----
Grzegorz Wiktorowski
OiOK
Tim Young
<< I use FlashFiler with xQuery component that provides SQL (much more than
simple SELECT). >>
I'm not sure if you're implying that DBISAM only supports a simple SELECT
statement or not, but just for the record we support everything that the BDE
supports except for UNION.
Paul Motyer
> Luckily, I was able to create the table structure and import the 200000
> records from an ASCII fixed file.
>
> I did not time it, but appending the 200000 records to the FF table took
> some 15-20 minutes or so, in any case much longer than the 2.75 minutes
with
> DBISAM 2.03 on my Windows 98 system.
Ole, here's an abridged version of the email I sent you half an hour ago
I slightly modified your source to work with
Flash Filer and here's the output:
[Should anyone want the source or EXE file just ask and I'll
post them to borland.public.attachments]
-----------------------------------------
"Ole Willy Tuv" <ow...@online.no> wrote:
> Hi Paul,
> Enclosed please find a zipped version of my
> DBISAM test project
This is a Client+Server App in the one EXE (SingleEXE):
Flash Filer appended 200000 records in - 77321 ms
Open and traverse test
Flash Filer a_table opened in 10 ms - 200000 records
Flash Filer a_table - Time: 20 ms - 1000 records processed - repeat 1
Flash Filer a_table - Time: 230 ms - 10000 records processed - repeat 1
Flash Filer a_table - Time: 1092 ms - 30000 records processed - repeat 1
Flash Filer a_table - Time: 1572 ms - 50000 records processed - repeat 1
Flash Filer a_table - Time: 2864 ms - 100000 records processed - repeat 1
Flash Filer a_table - Time: 4957 ms - 200000 records processed - repeat 1
Paul Motyer
Paul Motyer
> Just so you know, full source code has been an option since June when we
> shipped version 2.0. Also, we now ship the source code to all of the
> utilities with every version, even the trial versions.
This is a big improvement.
--
Paul Motyer
Paul Motyer
> I did not time it, but appending the 200000 records to the FF table took
> some 15-20 minutes or so, in any case much longer than the 2.75 minutes
> with DBISAM 2.03 on my Windows 98 system.
I slightly modified Ole's source to work with
Flash Filer and FF took 70 sec to 80 sec (different runs)
This is a Client+Server App in the one EXE (SingleEXE)
This is a similar speed to Paradox/BDE+ Local Share false.
I've sent the source and exe to Ole so he can test it on his machine.
Hopefully he'll post the result.
Please note that this is a Single User App - not multi-user.
Multi-User FF Apps are not this fast.
Should anyone else want the source or EXE file just ask and I'll post
them to borland.public.attachments
Paul Motyer
Paul Motyer
> I can confirm that the append test flies
> even faster on my system,
> 200000 records appended in 37 seconds here.
I thought my drive needed defragmenting!
> However, to make a realistic comparison, could
> you make an exact multi-user
> clone of my test project with FF as back-end,
> using transactions which is
> what I've been testing for
Well, a multi-user test should involve multple
users simultaneously accessing the data.
This is the scenario where Client Server typically
shines in comparison to Shared File systems.
I said the *FF single user* is fast - and it is
quite a bit faster than DBISAM in this case.
I sent you the source so you can see it's very
much the same as your code: it's using 250
records per transaction (same as your code)
The core FF engine is VERY fast
(as evidenced by the Single user speed)
A multi user FF App is a Client Server one.
Client Server is robust: Turbopower don't even
have a Repair Utility - because it's not needed.
This comes at a cost, though: interprocess
communication delay times mean it's slower
than a Shared File system when the number
of connections is small
In this test code there's only one connection!
Any Client Server App will suffer these same delays
On my machine, a FF Client-Server (SeparateEXE)
with both the Client App and the Server running
on the same computer and commumicating via
TCP/IP sockets with one user gives:
Flash Filer appended 200000 records in - 366547 ms
(6 minutes and 6.547 sec)
The reason it seems slow is that each record is sent
one-by-one thus multiplying the interprocess
communication delay. This can be largely avoided
by amalgamating the appends into batches.
Here's the DBISAM result on my machine:
DBISAM 2.03 TDBISAMQuery appended 200000
records in 233806 ms (3 min 53.806 sec)
Of course it's faster - because it is a Shared file
access system not Client Server, and there's only one client
Note also that these comparisons favour Shared file
systems because the test involves one Client only.
Client-Server shines where there are multiple users.
Single User speed is important but so is scalability
---
Paul Motyer
Paul Motyer
> I can confirm that the append test flies
> even faster on my system,
> 200000 records appended in 37 seconds here.
I thought my drive needed defragmenting!
> However, to make a realistic comparison, could
> you make an exact multi-user
> clone of my test project with FF as back-end,
> using transactions which is
> what I've been testing for
Well, a multi-user test should involve multiple
users simultaneously accessing the data.
This is the scenario where Client Server typically
shines in comparison to Shared File systems.
I said the *FF single user* is fast - and it is
quite a bit faster than DBISAM in this case.
I sent you the source so you can see it's very
much the same as your code: it's using 2500
JerryG
that local sql does not even though I set the indexes with case
insensitive and maintained.
Jerry G.
Grzegorz Wiktorowski
>I'm not sure if you're implying that DBISAM only supports a simple SELECT
>statement or not, but just for the record we support everything that the
BDE
>supports except for UNION.
>
No. I mean that xQuery components goes far beyond BDE.
-----
Grzegorz Wiktorowski
OiOK
Tim Young
<< No. I mean that xQuery components goes far beyond BDE. >>
Just curious - in what fashion ?
Tim Young
<< I said the *FF single user* is fast - and it is quite a bit faster than
DBISAM in this case. >>
Just a clarification - DBISAM is running in shared mode in the tests that
Ole is running. DBISAM is much faster when it has exclusive access to a
table or tables.
Eivind Bakkestuen
improved attention. They are also cranking away at version 2 (due sometime
this year), I expect it to be "the one to own". :-)
Eivind
"Bruce Roberts" <no.junk.p...@attcanada.net> wrote in message
news:8o9670$8e...@bornews.borland.com...
BF Deleen
in his analysis and comparison. He presents sound arguments, supported by
data and tests. He corrects flawed tests of others and challenges a counter.
Accordingly your comment about the other brush has no basis. This is not
about feelings, beliefs or brand loyalty. It's the scientific method or
nothing on this one.
"Mike Orriss (TeamB)" <m...@3kcc.co.uk> wrote in message
news:VA.00001c1a.14a7c173@mikemain...
> In article <39a71942_1@dnews>, Paul Motyer wrote:
> > Look at the Subject line. Most of the responders just
> > chant the DBISAM mantra. It does annoy me that so
> > many evangelize DBISAM and make claims about
> > Flash Filer that I consider mis-leading.
> >
>
> From where I'm sitting it looks like you are tarred with the other brush
> <g>
>
> I own both products but must admit that I have never deployed anything
> using FF (I probably bought the product far too early and never got to
> grips with it). In the meantime, DBISAM provided SQL support and so I
> don't even consider FF for new apps.
>
>
Paul Motyer
> << I said the *FF single user* is fast - and it is quite a bit faster than
> DBISAM in this case. >>
>
> Just a clarification - DBISAM is running in shared mode in the tests that
> Ole is running. DBISAM is much faster when it has exclusive access to a
> table or tables.
Maybe Ole would care to flick the exclusive switch and post the
comparitive results?
--
Paul Motyer
Tim Young
<< It's clear that Mr. Motyer has been the most accurate, precise and
factual in his analysis and comparison. He presents sound arguments,
supported by data and tests. He corrects flawed tests of others and
challenges a counter. >>
Not to be over-argumentative here, but there's only been one test conducted
informally, and it hardly reveals anything about either product's
performance. We've done our own internal benchmark suites against very
large tables using FlashFiler and many other database engines and are quite
comfortable with where DBISAM stands in respect to the performance
comparisons.
As for the tests being flawed, Ole did an excellent job on the insert
benchmark that he gave to Paul and it was not flawed in any way. Paul
simply used a special compilation of a single-user FlashFiler that improved
FlashFiler's standing in this particular performance comparison. I
certainly don't view this as a correction of a flawed test.
Paul Motyer
> As for the tests being flawed, Ole did an excellent job on the insert
> benchmark that he gave to Paul and it was not flawed in any way.
I agree Ole's insert benchmark is fine. He may also wish to include
a FindKey and backwards traversal speed check.
Ole calls this a "multi-user test project". Unless multiple instances
are run then it may be a mis-nomer.
The test is not flawed but it is in the *interpretation* that we need
to carefully assess the results.
In a multi-user environment this test indicates how an un-optimized
multi-user FF App is slower than DBISAM when there is only
one Client.
If we are only using one client then I don't think we're fairly
testing a multi-user App.
> Paul simply used a special compilation of a
> single-user FlashFiler
And THAT'S the point:
In a single-user environment FlashFiler can hold its own.
But also: in a *multi-user* environment FlashFiler can hold its own.
The only really valid criticism of FF is it's lack of SQL - and this
should be addressed with FF2
As far as optimization goes, FF can be optimized as I'm sure
DBISAM can
If I'm allowed to make some basic optimizations we can get
different results. For example, in FF we can batch appends
into groups. This reduces inter-process communication delays.
Here's a comparo using batches of 50 records:
Flash Filer appended 200000 in 88898 ms (Using Batches)
DBISAM 2.03 appended 200000 in 233806 ms
Flash Filer appended 200000 in 361790 ms (Without Batches)
I've sent this Multi-User App and source to Ole after he asked.
I'll happily send it to borland.public.attachments as well should
anyone wish to look.
--
Paul Motyer
Tim Young
<< And THAT'S the point: In a single-user environment FlashFiler can hold
its own. >>
Which is fine, but DBISAM is not getting the benefit of being able to
exclusively open and cache it's tables in the comparison, while FF is.
That may seem like a fine point, but it makes a big difference in speed.
Add in shared OS locking calls and multi-user change detection and you have
a lot of work that DBISAM is doing that FF is not. That is what Ole meant
when he said that the test was set up for multi-user access.
<< If I'm allowed to make some basic optimizations we can get different
results. For example, in FF we can batch appends into groups. This reduces
inter-process communication delays.
Here's a comparo using batches of 50 records:
Flash Filer appended 200000 in 88898 ms (Using Batches)
DBISAM 2.03 appended 200000 in 233806 ms
Flash Filer appended 200000 in 361790 ms (Without Batches) >>
Well, I'll just say this - we can do many things in our SQL benchmarks that
we've published in order to make DBISAM faster than it already is in the
benchmarks. Why don't we ? Because then the test is not accurate since
it's not comparing the same generic operations across multiple engines.
Some engines are good at some things while others are good at other things,
and the only way to know for sure is to leave out any engine-specific
optimizations that have to be manually introduced.
Ole Willy Tuv
> Maybe Ole would care to flick the exclusive switch and post the
> comparitive results?
Actually, I only use Query components in my test project which was
originally made to do a comparison between Sybase ASA 7, Advantage ALS 2.7
and DBISAM V2, all SQL engines. Lately, I've added InterBase 6 to the test.
At the time I made this project, I had not even heard about FF <g>
Well, I compiled a TDBISAMTable version of the project and opened the table
excusivly. The append test executed in 100 seconds.
Of course, reading those test results, one should be aware that the speed
rate of inserting records to a table, is very much dependant on what the
engine actually does. You mentioned indices in an earlier post. DBISAM,
being an SQL engine, does quite some bit of statistical maintenance as well
to enable optimised queries. In addition DBISAM maintain a rather complex
index which reuses deleted space automatically. On my system, it's no
problem to write 200000 records with the same structure to a pascal file in
10 seconds.
Thanks for sending me the new FF multi-user test application.
I've justed tested it on my system with the following result for the append
test:
Standard mode - 362257 ms
Using batches - 74237 ms
I'll send you a complete test report for all engines testet so you can
review how FF 1.56 compares to the other engines in all the tests, execept
for the 10-ways join test which FF is not capable of doing in current
version.
For others interested, I include a subset of the results below.
Finally, I want to thank you for an interesting discussion where you've made
good points about FF. I've never used it myself, but I have no reason to
doubt the qualities of FF. I'm sorry if I did upset you with my response to
a FF question. I've been very satisfied with DBISAM V2 and the excellent
support provided by the developers. I'm not associated with Elevate Software
in any ways.
Nice to meet you, Paul.
Best regards
Ole Willy Tuv
Test results:
----------------------------------------------------------------------------
--
Append test:
NativeDB 1.86 TAsaSQL appended 200000 records in 173420 ms
NativeDB 1.86 TAsaDataset appended 200000 records in 211485 ms
DBISAM 2.03 TDBISAMQuery appended 200000 records in 164292 ms
Advantage ALS 2.70 TAdsQuery appended 200000 records in 356431 ms
InterBase 6 TIBQuery appended 200000 records in 156029 ms
Flash Filer appended 200000 records in - 362257 ms
Flash Filer appended 200000 records in - 74237 ms (using batches)
Simle traverse test:
NativeDB 1.86 TAsaSQL opened in 266 ms
NativeDB 1.86 TAsaSQL - Time: 90 ms - 1000 records processed
NativeDB 1.86 TAsaSQL - Time: 859 ms - 10000 records processed
NativeDB 1.86 TAsaSQL - Time: 2733 ms - 30000 records processed
NativeDB 1.86 TAsaSQL - Time: 4351 ms - 50000 records processed
NativeDB 1.86 TAsaSQL - Time: 8313 ms - 100000 records processed
NativeDB 1.86 TAsaSQL - Time: 15965 ms - 200000 records processed
Total time: 16231 ms
NativeDB 1.86 TAsaDataset opened in 369 ms
NativeDB 1.86 TAsaDataset - Time: 85 ms - 1000 records processed
NativeDB 1.86 TAsaDataset - Time: 1000 ms - 10000 records processed
NativeDB 1.86 TAsaDataset - Time: 2923 ms - 30000 records processed
NativeDB 1.86 TAsaDataset - Time: 4562 ms - 50000 records processed
NativeDB 1.86 TAsaDataset - Time: 8587 ms - 100000 records processed
NativeDB 1.86 TAsaDataset - Time: 16473 ms - 200000 records processed
Total time: 16842 ms
DBISAM 2.03 TDBISAMQuery opened in 39 ms
DBISAM 2.03 TDBISAMQuery - Time: 29 ms - 1000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 723 ms - 10000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 2278 ms - 30000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 3769 ms - 50000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 7790 ms - 100000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 15616 ms - 200000 records processed
Total time: 15655 ms
Advantage ALS 2.70 TAdsQuery opened in 501 ms
Advantage ALS 2.70 TAdsQuery - Time: 103 ms - 1000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 1623 ms - 10000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 3950 ms - 30000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 6906 ms - 50000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 13588 ms - 100000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 26014 ms - 200000 records processed
Total time: 26515 ms
InterBase 6 TIBQuery opened in 9 ms
InterBase 6 TIBQuery - Time: 141 ms - 1000 records processed
InterBase 6 TIBQuery - Time: 1449 ms - 10000 records processed
InterBase 6 TIBQuery - Time: 4737 ms - 30000 records processed
InterBase 6 TIBQuery - Time: 7930 ms - 50000 records processed
InterBase 6 TIBQuery - Time: 15832 ms - 100000 records processed
InterBase 6 TIBQuery - Time: 43623 ms - 200000 records processed
Total time: 43632 ms
Flash Filer a_table - Time: 324 ms - 1000 records processed
Flash Filer a_table - Time: 1737 ms - 10000 records processed
Flash Filer a_table - Time: 4992 ms - 30000 records processed
Flash Filer a_table - Time: 8250 ms - 50000 records processed
Flash Filer a_table - Time: 15910 ms - 100000 records processed
Flash Filer a_table - Time: 36339 ms - 200000 records processed
Total time: 36344 ms
Extensive traverse test:
NativeDB 1.86 TAsaSQL opened in 318 ms
NativeDB 1.86 TAsaSQL - Time: 438 ms - 1000 records processed
NativeDB 1.86 TAsaSQL - Time: 1621 ms - 10000 records processed
NativeDB 1.86 TAsaSQL - Time: 4152 ms - 30000 records processed
NativeDB 1.86 TAsaSQL - Time: 6415 ms - 50000 records processed
NativeDB 1.86 TAsaSQL - Time: 12096 ms - 100000 records processed
NativeDB 1.86 TAsaSQL - Time: 23273 ms - 200000 records processed
Total time: 23591 ms
NativeDB 1.86 TAsaDataset opened in 386 ms
NativeDB 1.86 TAsaDataset - Time: 171 ms - 1000 records processed
NativeDB 1.86 TAsaDataset - Time: 1879 ms - 10000 records processed
NativeDB 1.86 TAsaDataset - Time: 5652 ms - 30000 records processed
NativeDB 1.86 TAsaDataset - Time: 9275 ms - 50000 records processed
NativeDB 1.86 TAsaDataset - Time: 18104 ms - 100000 records processed
NativeDB 1.86 TAsaDataset - Time: 35657 ms - 200000 records processed
Total time: 36043 ms
DBISAM 2.03 TDBISAMQuery opened in 45 ms
DBISAM 2.03 TDBISAMQuery - Time: 93 ms - 1000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 1360 ms - 10000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 4269 ms - 30000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 7067 ms - 50000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 14487 ms - 100000 records processed
DBISAM 2.03 TDBISAMQuery - Time: 29100 ms - 200000 records processed
Total time: 29145 ms
Advantage ALS 2.70 TAdsQuery opened in 479 ms
Advantage ALS 2.70 TAdsQuery - Time: 215 ms - 1000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 2475 ms - 10000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 7179 ms - 30000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 12275 ms - 50000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 24568 ms - 100000 records processed
Advantage ALS 2.70 TAdsQuery - Time: 48616 ms - 200000 records processed
Total time: 49095 ms
InterBase 6 TIBQuery opened in 9 ms
InterBase 6 TIBQuery - Time: 187 ms - 1000 records processed
InterBase 6 TIBQuery - Time: 1911 ms - 10000 records processed
InterBase 6 TIBQuery - Time: 5931 ms - 30000 records processed
InterBase 6 TIBQuery - Time: 10176 ms - 50000 records processed
InterBase 6 TIBQuery - Time: 20582 ms - 100000 records processed
InterBase 6 TIBQuery - Time: 52719 ms - 200000 records processed
Total time: 52728 ms
Flash Filer a_table - Time: 304 ms - 1000 records processed
Flash Filer a_table - Time: 2115 ms - 10000 records processed
Flash Filer a_table - Time: 6182 ms - 30000 records processed
Flash Filer a_table - Time: 10146 ms - 50000 records processed
Flash Filer a_table - Time: 19798 ms - 100000 records processed
Flash Filer a_table - Time: 39475 ms - 200000 records processed
Total time: 39481 ms
Paul Motyer
> Well, I compiled a TDBISAMTable version of the project
> and opened the table excusivly.
> The append test executed in 100 seconds.
... about 2.7 times slower than FF SingleEXE (37 sec)
Flash Filer was released in early 1997 with full source so
it's pretty well debugged by now.
So, I think it's quite fair to state that there are reliable, robust,
well supported and feature rich engines that may be faster than
DBISAM (at least in Single User and in the features of your
test) - despite repeated posts to the contrary that DBISAM
is the "best" and "fastest"
For those who need SQL it should arrive with FF2
> In addition DBISAM maintain a rather complex
> index which reuses deleted space automatically.
FF reuses space automatically using an internal maintenance index too.
> For others interested, I include a subset of the results below.
Please remember when reviewing the results that these tests are
comparing a Client Server App with a Shared File App
and with only one Client.
This comparo is an oranges v apples one. In general, as Clients
are added the relative results of the C/S engines should improve
(and overtake) the Shared File engines.
Optimizing each engine is only being realistic. In the real world you work
to the strengths of your tools and optimize (at least minimally).
I apologize for my long winded posts - I am normally only a lurker here.
I'll try and go back into my shell now. FF *IS* worth considering.<G>
--
Paul Motyer
David Marcus
> > - FF is being actively developed (by a team of 3 or 4)
I believe it is 3.
> This must be a new development. One of the consistent NG complaints about FF
> in the past has been that TP has not been doing anything with the product.
Yes, things have changed dramatically in the last year or so. TP hired
three new people who, I believe, are working on FF full-time. All three
post in the support newsgroup. The lead developer announced in the ng
that FF 2 will be out by the end of the year.
--
David Marcus
Tim Young
<< Flash Filer was released in early 1997 with full source so it's pretty
well debugged by now. >>
I'm not sure where you're headed with this, but it has also had relatively
few new features in that time frame also, hence one would expect it to be
quite stable.
<< So, I think it's quite fair to state that there are reliable, robust,
well supported and feature rich engines that may be faster than DBISAM (at
least in Single User and in the features of your
test) - despite repeated posts to the contrary that DBISAM is the "best" and
"fastest" >>
Our own benchmarks on our web site indicate that we aren't the "best" or
"fastest" at everything, however we are overall very much in the top engines
in terms of performance when it comes to the SQL benchmarks. We also hold
our own quite well in terms of insert and update speeds, but in most cases
huge batches of inserts are hardly a good test for the overall performance
of an engine.
<< For those who need SQL it should arrive with FF2 >>
In the interest of scientific thoroughness (<g>), we should re-convene this
thread after FF2 is available and we have run it through our SQL benchmark
suite. Sound fair ?
Tim Young
<< Just stating facts. The implication is obvious. I didn't mention that
the core engine was based on B-Tree Filer the code for which has been
scrutinized for many, many years Imagine the VCL source was not available -
faulty code would be hard to pin down. The longer the code is available to
scrutiny by all customers the less bugs will remain un-squished. >>
That's quite a stretch - just because the source is available does not mean
any of the customers are checking it for bugs or are qualified to determine
if there's a bug. Database engines are not simple in any respect, and
require quite a bit of knowledge in that specific area of expertise to
understand the reasonings behind the way things are coded.
<< Many NG posts *suggesting* the contrary notwithstanding (not by you).
Want me to compile some examples? >>
And your point is ? You have yet to show completely that they are entirely
incorrect - as I said earlier, one test hardly paints the entire picture.
<< How about: when FF2 is released AND DBISAM Client/Server is released
(been promised for a long time) THEN we can compare apples to apples; it
might even be fair to use YOUR benchmark suite. >>
*Might* be fair ? It's straight SQL-92, it doesn't get any more fair than
that. <g>
<< Notice how no-one compiled, ran and posted the results for DBISAM for the
example code I posted for 1 million inserts? >>
And again, what are you getting at ? We've done tests with DBISAM and FF
with that many records and FF tends to be quite a bit slower at setting a
range that includes a large number of the million records compared to
DBISAM. There were some other areas that were distinctly different, but
I'd have to dig them up.
<< When SQL is added to FF we should JUST test SQL performance to compare it
to other engines? >>
Well, we decided on SQL since it was the only common denominator among all
of the engines. Testing navigational speed against a SQL server database
engine is a bit suspect since we all know that they usually stink at such
things.
<< Turbopower's marketing style is a bit restrained for my tastes; maybe
they should be more vocal. But right now, FF is a quality database engine in
both Single User and Client Server modes. >>
Nobody said it wasn't, the only thing that started this whole thing was a
recommendation to use DBISAM (not by anyone from Elevate Software) which,
for some reason, didn't sit well with some folks.
Paul Motyer
> << Flash Filer was released in early 1997 with full source so it's pretty
> well debugged by now. >>
>
> I'm not sure where you're headed with this
Just stating facts. The implication is obvious. I didn't
mention that the core engine was based on
B-Tree Filer the code for which has been scrutinized
for many, many years
Imagine the VCL source was not available - faulty code
would be hard to pin down.
The longer the code is available to scrutiny by all customers
the less bugs will remain un-squished. When something
unexpected happens tracing into the code has no substitute.
> Our own benchmarks on our web site indicate that we
> aren't the "best" or "fastest" at everything
Many NG posts *suggesting* the contrary notwithstanding
(not by you). Want me to compile some examples?
> we should re-convene this thread after FF2 is available and we have
> run it through our SQL benchmark suite. Sound fair ?
How about: when FF2 is released AND DBISAM Client/Server is
released (been promised for a long time) THEN we can
compare apples to apples; it might even be fair to use YOUR
benchmark suite.
Notice how no-one compiled, ran and posted the results for
DBISAM for the example code I posted for 1 million inserts?
When SQL is added to FF we should JUST test SQL
performance to compare it to other engines?
Turbopower's marketing style is a bit restrained for my tastes;
maybe they should be more vocal. But right now, FF is a quality
database engine in both Single User and Client Server modes.
--
Paul Motyer
Eryk
> > << Flash Filer was released in early 1997 with full source so it's
pretty
> > well debugged by now. >>
> >
> > I'm not sure where you're headed with this
>
> Just stating facts. The implication is obvious. I didn't
> mention that the core engine was based on
> B-Tree Filer the code for which has been scrutinized
> for many, many years
You're right, the implication *is* obvious ....you're implying that DBISAM
is unreliable and has not been competently debugged. If you want to conduct
the debate on that level then go ahead but we're not going down that route
with you ....we have the greatest respect for the guys behind FlashFiler and
we won't be drawn into a debate based on unsubstantiated mud slinging.
> Many NG posts *suggesting* the contrary notwithstanding
> (not by you). Want me to compile some examples?
Your implication being that Sean and Julian should take responsibility for
your comments?
> How about: when FF2 is released AND DBISAM Client/Server is
> released (been promised for a long time) THEN we can
> compare apples to apples; it might even be fair to use YOUR
> benchmark suite.
No it wouldn't. Our benchmark suite specifically prohibits the use of any
engine specific optimisation, you've already stated you don't think it is
realistic to expect a database forego such advantages.
> When SQL is added to FF we should JUST test SQL
> performance to compare it to other engines?
Test whatever you like. We focus on SQL because it depends on the low level
navigational functions in the end and therefore gives an overall view of
performance.
> Turbopower's marketing style is a bit restrained for my tastes;
> maybe they should be more vocal. But right now, FF is a quality
> database engine in both Single User and Client Server modes.
...and I don't recall us disputing that. You're the one who started throwing
accusations of inferior 'quality' around (see paragraph one) not us.
Eryk
--
Elevate Software
www.elevatesoft.com
Eldon Yeung
as my company use both FF and DBISAM in our application. Both are great
products, in terms of performance, ease of use and stability. However,
neither of each can fulfill all of our needs in every occasion. The
following summarize our findings:
STABILITY
Much much better than BDE for both products. However, the probability of
table corruption for F/S DBs is still higher than C/S DBs. Furthermore, the
F/S data can be easily corrupted by any careless user that can access the
data file.
SUPPORT
Both offering responsive supports and NGs to support their product. FF's
open source policy is an absolute advantage in gathering more technical
people to support and debug their product. FF is also posting interim bug
fixes to the NG before the final release is available that really help us a
lot. (BTW, we are still waiting the bug fix versions: FF1.57 and DBISAM
1.22 for a while.)
EASE OF USE
DBISAM is easiler in developing single/multi user application as only one
'.exe' is required for compilation and distribution.
IMPLEMENTATION
DBISAM is easiler in implementation and no server setup is required. The
only thing to set up the application for multi-user access is to let the
data directory sharable.
SQL
Although most of the SQL statements can be replaced by some native Table and
Index access statements, the added codes would complicate the development of
the application.
PERFORMANCE
Both products can deliver acceptable performance in single user mode.
However, FF is definitely the winner in multi-user mode, especially when the
number of users is increasing. For remote offices that connect to the
server through 64K data lines, C/S DBs are the only solutions.
FUTURE VERSION
FF 2.0 will have SQL and DBISAM 2.X will offer C/S support. In terms of
complexity, IMHO, adding SQL support is more complicate than building a C/S
layer.
Before the new versions of both products that are planned to release some
time this year, I would recommend to use
DBISAM if you think the followings are important
- ease of deployment for both single and multi-user environments
- SQL support
- simple multi-user environment set up
- no dedicate DB server
or FF if you think the followings are important
- multi-users performance
- access over WAN or Internet
- over 20 active concurrent accesses
- highest DB integrity and better control on data
Paul Motyer
You are mis-interpreting what I write, jumping to
strange conclusions and then accusing me falsely
and being very nasty about it
I don't wish to persist or respond at this level
I've written some notes below because your words
are un-kind but hope I can control myself enough
that I won't respond if this stays at this level.
"Eryk" wrote
> You're right, the implication *is* obvious ....
> you're implying that DBISAM
> is unreliable and has not been competently debugged.
Huh? Where do you get that from? This is just plain wrong.
Re-read what I wrote and maybe you'll see I was writing
about FF and its code. Read what else is on that
paragraph: it's about FF
No code is "completely debugged" not FF's, not mine and
not yours. But I wasn't suggesting anything re DBISAM
I was commenting that the FF code had been scrutinized
over a long time by many people. I'm sure FF still
has bugs. Are you implying DBISAM has none?
Get real.
> If you want to conduct
> the debate on that level then go ahead but we're not
> going down that route with you ....
Huh? It's not me going down.
> we have the greatest respect for the guys behind
> FlashFiler and we won't be drawn into a debate
> based on unsubstantiated mud slinging.
Huh? You've made it all up.
Who's slinging mud? Take a good hard look. I haven't.
> Your implication being that Sean and Julian should
> take responsibility for your comments?
No - what a ludicrous idea. I was saying, I thought pretty
clearly, that the impression in the general community
might be that DBISAM was the best thing since
sliced bread. This impression being given because
many posts say basically just that.
Now YOU seem to think I hold Elevate Software
responsible. Why I don't know. Maybe, if you will
re-read what I wrote, you'll see it.
Maybe that's why you've decided to flame me.
> > How about: when FF2 is released AND DBISAM Client/Server is
> > released (been promised for a long time) THEN we can
> > compare apples to apples; it might even be fair to use YOUR
> > benchmark suite.
>
> No it wouldn't. Our benchmark suite specifically prohibits
> the use of any engine specific optimisation, you've already
> stated you don't think it is
> realistic to expect a database forego such advantages.
I think you're right here.
So do the MySQL developers apparently:
http://www.greatbridge.com/news/p_082220001.html
> You're the one who started throwing
> accusations of inferior 'quality' around
> (see paragraph one) not us.
This is just plain not true.
You are *re-interpreting* what I say and then falsely
accusing me. I NEVER said nor implied that DBISAM was
of inferior 'quality'.
That's just total rot.
---
Paul Motyer
Paul Motyer
> That's quite a stretch - just because the source is
> available does not mean any of the customers are
> checking it for bugs or are qualified to determine
> if there's a bug.
True, it doesn't mean that in general; however, in the
case of FF, that is was HAS happened
> *Might* be fair ? It's straight SQL-92, it doesn't
> get any more fair than that. <g>
Let's agree to disagree on this. Maybe it is a fair test
That's why I said "might"
For example, does your benchmark do any multiple Client
stress testing?
Please do not interpret the following as a personal criticism:
I've never seen your benchmark. You act, though, as if your
benchmark is the industry standard. I would expect most people
to realize that NO benchmark is fair - designing a fair database
engine benchmark is no simple task.
Witness the recent MySQL/PostgreSQL/Interbase etc benchmark dispute:
http://www.mysql.com/information/benchmarks.html
http://www.greatbridge.com/news/p_081420001.html
and http://www.greatbridge.com/news/p_082220001.html
> << Notice how no-one compiled, ran and posted the results for DBISAM for
the
> example code I posted for 1 million inserts? >>
>
> And again, what are you getting at ?
Why do think I mean anything different to what I write?
> We've done tests with DBISAM and FF
Yeah. You could have ran that code in one tenth the time
it took to respond to my post.
> Nobody said it wasn't, the only thing that started this whole thing was a
> recommendation to use DBISAM (not by anyone from Elevate Software) which,
> for some reason, didn't sit well with some folks.
Now I'll make a presumption. I presume you mean me.
If that's right then you're wrong. I have nothing against
anyone recommending DBISAM. No.
It's when they say DBISAM is the best and fastest so use that
when the poster asked: "What's the skinny on FF?"
Again: I have nothing against anyone recommending DBISAM.
But when I give concrete examples which suggest otherwise
and give positive info about FF's history I get flamed by
Elevate Software (see Eryk's post if you don't believe me.
BTW, I think that post is reprehensible)
---
Paul Motyer
Jimmy Harlindong
> stress testing?
This is exactly what I *think* is wrong with DBISAM's tests that were posted
on their web site.
About my experience with running insert operations in one program and SELECT
* in another.... I still want to see how dbisam can do it faster than what I
have seen (which is slow)? Any demos I can run myself ? I am not flaming,
just want to see it. If it is fast enough, it will make me happy :)
Eryk
> You are mis-interpreting what I write, jumping to
> strange conclusions and then accusing me falsely
> and being very nasty about it
I reviewed what you wrote several times because I didn't believe you could
be headed down that route. That's why we specifically asked for
clarification:
> << Flash Filer was released in early 1997 with full source so it's pretty
> well debugged by now. >>
>
> I'm not sure where you're headed with this
>Just stating facts. The implication is obvious.
...and you declined to provide any. The only remaining explanation is that
it's a random statement of fact with no relevance to this branch of the
conversation and it didn't seem logical to draw that conclusion.
> I don't wish to persist or respond at this level
My reaction precisely.
> Huh? Where do you get that from? This is just plain wrong.
> Re-read what I wrote and maybe you'll see I was writing
> about FF and its code. Read what else is on that
> paragraph: it's about FF
No it's not, it's a comparative statement regarding FlashFiler and DBISAM,
in fact DBISAM is the only product mentioned with FF included by implication
(along with at least one other un-named product ....your use of 'other' and
'engines').
> No code is "completely debugged" not FF's, not mine and
"Compentently", not "Completely" .....no-one is making any claims about
being bug free.
> I was commenting that the FF code had been scrutinized
> over a long time by many people. I'm sure FF still
> has bugs. Are you implying DBISAM has none?
Unless you're drawing some sort of comparison from this I still have to
respond "So What?". Lengthy scrutiny of a code base has no relevance other
than the potential to reduce the bug count, however unless it actually
improves stability vs. competitors who have taken a different route (which
you say is not your implication ...see para 1) then it has no meaning.
> Huh? You've made it all up.
> Who's slinging mud? Take a good hard look. I haven't.
I'm glad to be able to return to my original view that this could not be
what you intended and I apologise if I over-reacted. I'm afraid I still
don't see what you're getting at with your references to the age of the FF
code base though ....InterBase has been around for about 15 years .....So
What? Having greater stability than product 'x' or a more highly tuned query
optimiser than product 'y' are the genuine issues, InterBase dosen't win any
prizes simply for being 'old'.
> No - what a ludicrous idea. I was saying, I thought pretty
> clearly, that the impression in the general community
> might be that DBISAM was the best thing since
> sliced bread. This impression being given because
> many posts say basically just that.
OK, so why bring it up? Traditionally this sort of thing is counteracted by
advertising the strengths of your own favoured product, not by complaining
about the existence of differing views.
> Maybe that's why you've decided to flame me.
Like I said, it's a misunderstanding just as you mis-read "Competent" as
"Complete" in the "bug" paragraph and proceeded to respond on the basis that
I was making silly claims about DBISAM's bug count. I'm probably being
monumentally stupid, but I *really* didn't and (don't) understand the
'obvious' implication that started this. Since you didn't mean what I took
you to mean I cannot see an implication at all ...it's just a random
statement of fact with no relevance to the context (speed of appends).
> I think you're right here.
> So do the MySQL developers apparently:
> http://www.greatbridge.com/news/p_082220001.html
I'm not surprised. Tuning can have a significant impact on the performance
of many engines so I'd expect any losing vendor (as MySQL was in that test)
to suggest improvements. The fact remains that many users have no desire to
become intimately familiar with the internal workings of a database engine
and want a 'black box' which processes vanilla SQL92 as quickly as possible.
An 'out of the box test' is therefore a valid comparison (IMO) if not a
complete one (no benchmark is ever 'complete' in that sense).
> You are *re-interpreting* what I say and then falsely
> accusing me. I NEVER said nor implied that DBISAM was
> of inferior 'quality'.
Then this entire issue is one big misunderstanding and I apologise.
![Support Technique [Eurice]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVEbXAhls9Iywmg9_K4ExfG27FRMVH84MWIULEm0cYyUnIkQA=s40-c)
Support Technique [Eurice]
'guru' : Julian M. Bucknal.
"David Marcus" <david...@rcn.com> a écrit dans le message news:
MPG.14145550e...@newsgroups.inprise.com...
Grzegorz Wiktorowski
>EASE OF USE
>DBISAM is easiler in developing single/multi user application as only one
>'.exe' is required for compilation and distribution.
I disagree. I've never recompiled FF server. We distribute one installation
executable including FF server (out of box) and client apps. Users check
what they want to install. When everything runs only upgrades of client apps
are distributed and re-installed.
>
>IMPLEMENTATION
>DBISAM is easiler in implementation and no server setup is required. The
>only thing to set up the application for multi-user access is to let the
>data directory sharable.
>
Again I don't agree. We include FF server's scripts file to set it's
options. Without scripts files you have to choose the protocol type + two
checboxes. I don't think it's complicated.
Please remember that FlashFiler needen't any sharable directories. Client
apps communicate with FF server via transport layer (TCP/IP or IPX/SPX). One
of our application runs in NetWare 5 networks on NT workstations. And
FlashFiler server is stuck on Windows Terminal Edition/Metaframe server.
None of clients knows where the server and databases are located in the
network :). When a new person wants to access the database, an administrator
installs only client EXE on the workstation and sets the protocol type.
----------
Grzegorz Wiktorowski
OiOK
Support Technique [Eurice]
thread).
In fact, i'm also a user a FF for about 50 sites with a total of 500 seats.
Except few minor bugs, I never had any major issue with Flash Filer.
Few months ago, when I was searching for a database engine, I took a look
at DBISAM, FF, Pervasive...even to MsAccess....
I think FF is the right solution for datas reliability and security....even
over the Internet.....
And regarding to Advantage staff's discussion and how they reply to Paul's
messages....I greatly prefer FF Team's contact.
Bests regards from Paris to all of you...
"Eldon Yeung" <el...@brioec.com.hk> a écrit dans le message news:
39ab3b6c_2@dnews...
> I saw a lot of valuable comments here and would like to share some of
mine,
> as my company use both FF and DBISAM in our application. Both are great
> products, in terms of performance, ease of use and stability. However,
> neither of each can fulfill all of our needs in every occasion. The
> following summarize our findings:
>
> STABILITY
> Much much better than BDE for both products. However, the probability of
> table corruption for F/S DBs is still higher than C/S DBs. Furthermore,
the
> F/S data can be easily corrupted by any careless user that can access the
> data file.
>
> SUPPORT
> Both offering responsive supports and NGs to support their product. FF's
> open source policy is an absolute advantage in gathering more technical
> people to support and debug their product. FF is also posting interim bug
> fixes to the NG before the final release is available that really help us
a
> lot. (BTW, we are still waiting the bug fix versions: FF1.57 and DBISAM
> 1.22 for a while.)
>
> EASE OF USE
> DBISAM is easiler in developing single/multi user application as only one
> '.exe' is required for compilation and distribution.
>
> IMPLEMENTATION
> DBISAM is easiler in implementation and no server setup is required. The
> only thing to set up the application for multi-user access is to let the
> data directory sharable.
>
Jimmy Harlindong
Could you tell me how they will install the client exe without major fuss
about knowing what is the name of the server etc?
I am actually going to use Interbase, but since with Interbase you need to
specify the server name *and* the database including its *path* I think it's
a potential to be a "complicated" process.
I would appreciate if you could give me a hint on how to do this easily...
(hopefully not relying on tcp/ip as IB can be installed on pure netbeui /
ipx/spx)
TIA
Jerry Hayes
"Paul Motyer" <s...@the.sig.com> wrote in message news:39ab5c87$1_1@dnews...
[Snip]
> I would expect most people
> to realize that NO benchmark is fair - designing a fair database
> engine benchmark is no simple task.
Sure, the next thing you're going to tell us is that MS intentionally leaves
things out of its SQL7 TP tests just so it can beat Oracle and Db2 ;)
Brion L. Webster
news:8o71mn$h0...@bornews.borland.com...
> Brion, Can't IB6 be accessed across the internet ?
>
> e.g. "64.1.2.3:c:\database\mydiary.gdb" ?
>
I'm not sure, I wouldn't be surprised, though.
> ASTA is very nice *but* it's not royalty free (afaik). However seeing that
>
> Can anyone comment / clarify this please?
>
>
Grzegorz Wiktorowski
Sure. Drop me your e-mail address.
-----
Grzegorz
Alex Wong
> *Might* be fair ? It's straight SQL-92, it doesn't get any more fair than
> that. <g>
I don't think so. Your benchmark tests only tested a small subset of SQL
statements (see below) in single user mode with data located on the same
computer as the application, and the records in the result set are not
scanned, instead, only the record count is retrieved. It hardly has any
implication on how the engine will perform in real world application which
are usually multi-user, LAN/WAN environment.
Since the DBISAM benchmark is mentioned quite a few times in this
discussion, I cannot resist to add in my own opinions on that. I don't
think the benchmark is fair at all. The benchmark seems to specifically
tailored to handicap the Advantage Local Server (ALS). Whoever did
benchmark must had found one weakness (bug) in the ALS SQL engine and
exploit it for the benchmark. Specifically, the ALS did not optimize the
'column BETWEEN val1 and val2' type of restriction whereas the equivalent
comparison 'column >= val1 and column <= val2' is fully optimized in ALS
using index. Almost all of the tests in the DBISAM benchmark uses the
BETWEEN operator in the statement to guarantee a poor performance number for
ALS.
And I also think this is done intentionally to target ALS because: in the
first version of the benchmark that was published in May/June (?), there
were some statements using the >= and <= notation instead of the BETWEN
operator. In those tests, ALS actually showed better number than DBISAM.
In fact, in that version of the bench mark, if you exclude the statements
with the BETWEEN operator, ALS has better overall performance number than
DBISAM. I can show you the result if you want. In your second version of
the benchmark, there is not a single statement use the 'column >= val1 and
column <= val2' notation. How is that for fairness?
In general, one should be skeptical about the benchmark done by the same
company who is trying to sell the product. For what its worth, our
benchmark was done by an independent third party testing facility.
--
Alex Wong
Advantage R&D
Extended Systems Inc.
Eryk
> And there's the rub: after drawing your conclusions you
> just weighed straight in, flamethrower to the fore. No:
> "Whoa there! Am I reading this right? Are you implying ..."
It appeared to me that you had already answered the question. I thought the
potential for misunderstanding would be clear and that you would have taken
the previous opportunity to clarify. You will note that I was not responding
to your original statement but your re-iteration of it in the following
message.
> Did you review the WHOLE THREAD?
> The basic question was: How good is FF?
> That's the context. I was attempting to elucidate
> what I see as one of FF's positives.
Yes however it seemed that your speed oriented debate with Ole had
diversified the discussion to the point where FlashFiler was not the only
issue being discussed.
> That's BS. Why not read the whole section.
>
> Here's the "implication" if you need to
> find implications in what I write:
You're the one who stated that there was an implication, quote: "the
implication is obvious." Without that I might have concluded that it was a
simple statement of fact but you effectively stated that more should be read
into it.
> "The longer the code is available to scrutiny
> by all customers the less bugs will remain un-squished.
I disagree. Access to source code may make some bug reports more detailed
(though I see no evidence of it personally) but I've yet to encounter a bug
which could only be detected via source code (it would be debateable whether
such an issue really *was* a bug).
> There are many contributions in FF the source code of
> which were donated to Turbopower by FF users. They could
> only do this because the source was available.
They are mostly enhancements rather than bug fixes though ...fair?
> Many bugfixes have also been contributed by FF users.
Quite possibly but I'm convinced Julian would have nailed them himself
anyway. I'm sure source code bug reports with suggested fixes make his job a
bit easier, but I doubt it impacts significantly on the end result.
> You can't see any benefits gained from that? Seriously?
I can see the benefits in the enhancement arena and possibly making the
developer's job a little easier but I remain unconvinced about the bottom
line impact on overall product stability.
> Consider this then:
> If the BDE source were available I suggest to you it'd have
> been fixed long ago.
True, but it's not really a fair analogy since the BDE has had little
significant development resource devoted to it in recent years which is not
the case for either FlashFiler or DBISAM.
> > > Read what else is on that
> > > paragraph: it's about FF
> >
> > No it's not,
Not that paragraph, I was referring to the original.
> No, it's not the age it's the robustness, bug fixes and
> improvements gained by users examining the code and
> contributing. This can now happen with IB because the
> code's available
However it didn't happen over the last 15 years and I don't see any
particular stability concerns arising as a consequence.
> http://www.mysql.com/information/benchmarks.html
>
> The MySQL people reckon THEIR engine is better based on
> THEIR benchmarks
I don't doubt it. I've never bothered to look but I'd assume MSFT benchmarks
put SQL Server above Oracle and Oracle Corp. benchmarks do precisely the
opposite. That's why I'm opposed to allowing *any* engine specific tuning
....it often makes it possible to massage the figures.
> Eryk, I've reviewed several hundred of your posts
> (mainly on the elevatesoft NGs) and you're usually
> quite pleasant (as I guess one would be to one's customers).
> Why you never gave me the same common courtesy I don't know.
>
> If you interpreted what I wrote in such a way that it
> offended you then I apologize because that was never
> my intention. I don't hide behind "implications", if
> I thought your code was crap I'd say so. If I thought
> it excellent I'd say that, too.
The fact that you're not a customer didn't enter into it, it's just that the
one thing which never fails to annoy me is 'negative marketing' in general
and *especially* if it's based on implication and FUD rather than fact. If
you'd actually stated that in your opinion DBISAM was probably buggier than
FlashFiler then my reaction would have been a simple request for evidence
...it was what I misinterpreted as 'evasiveness' when we asked for
clarification that really annoyed me, not the implication itself.
The bottom line is that it's all been a misunderstanding, two different
views of what constituted 'obvious'.
Tim Young
<< True, it doesn't mean that in general; however, in the case of FF, that
is was HAS happened >>
To some extent, maybe, but I would say that in most cases the source code
was simply the roadmap to show the customer where the bug was (provided they
take the time to trace it down), not to evidence the bug in the first place
by reviewing it manually line-by-line.
<< Let's agree to disagree on this. Maybe it is a fair test That's why I
said "might" >>
That's fine, however just keep in mind that individual execution time of SQL
queries has a direct impact on how much work a server engine has to do and
dictates how much concurrent load it can take.
<< For example, does your benchmark do any multiple Client stress testing?
>>
We do multiple client stress testing, but this benchmark does not include
it. As I stated above, however, the benchmark can certainly give you an
idea of how well an engine will perform the same actions under a load of
multiple clients.
<< Please do not interpret the following as a personal criticism: I've
never seen your benchmark. You act, though, as if your benchmark is the
industry standard. I would expect most people
to realize that NO benchmark is fair - designing a fair database engine
benchmark is no simple task. >>
It's at:
http://www.elevatesoft.com/benchmrk.htm
Also, I don't personally care for the comment about the industry standard,
it's a bit under-handed and impunes something that myself and Eryk spent
months working on. It is *extremely* fair, especially to some of our
competitors that wouldn't execute standard SQL-92 queries. If you look at
it you'll notice that we lose in the areas that we're not good at and we win
in the areas that we are good at. We are able to provide the data and
queries that we used to anyone that cares to dispute any of the results.
Eryk can detail the whole thing for you if you'd like - you'll be shocked at
the lengths he went to to make sure that every test was clean.
<< Why do think I mean anything different to what I write? >>
Because you made a statement with seemingly no meaning to me whatsoever.
What is your point that no one ran the benchmark with 1 million records ?
You must have a point otherwise you've just stated the obvious, which is a
little silly.
<< Yeah. You could have ran that code in one tenth the time it took to
respond to my post. >>
Again, what are you saying here ? You seem to delight yourself in
conversing with veiled comments that require me to constantly clarify, and
the above comment has little or nothing to do with what my comment.
<< Now I'll make a presumption. I presume you mean me. >>
You certainly weren't alone.
<< If that's right then you're wrong. I have nothing against anyone
recommending DBISAM. No. It's when they say DBISAM is the best and fastest
so use that when the poster asked: "What's the skinny on FF?" >>
And, the problem with that is what ?
<< Again: I have nothing against anyone recommending DBISAM. But when I
give concrete examples which suggest otherwise and give positive info about
FF's history I get flamed by
Elevate Software (see Eryk's post if you don't believe me. BTW, I think
that post is reprehensible) >>
Eryk wasn't flaming you, so don't get your panties in a bunch - the problem
he (and I) are having with your messages is that you insist on making broad
statements about how FF is better because of things that really cannot be
proven (and one informal test), and in the process use thinly-disguised
comments about FF to impune our integrity (yes, your comments about our
benchmarks basically dance around the issue of whether we slanted the tests
in our favor) and the fact that DBISAM is indeed a very fast, very stable
database engine. Eryk and I both take this stuff very personally, as we
should since we put in many hours every day making sure that we've done the
best job we possibly can on the product.
Tim Young
<< This is exactly what I *think* is wrong with DBISAM's tests that were
posted on their web site. >>
Prove to me how they're wrong.
<< About my experience with running insert operations in one program and
SELECT * in another.... I still want to see how dbisam can do it faster than
what I have seen (which is slow)? >>
I think I already covered this - set RequestLive to True for the
TDBISAMQuery component. The benchmarks always have RequestLive set to True
since it's more compatible with the way MS Access processes their queries
(they're always "live", even with joins).
Eryk
> I think I already covered this - set RequestLive to True for the
> TDBISAMQuery component. The benchmarks always have RequestLive set to
True
> since it's more compatible with the way MS Access processes their queries
> (they're always "live", even with joins).
Also Advantage and Paradox effectively activate RequestLive when they deem
it appropriate whether the developer requests it or not.
Robert Schiller
> B-Tree Filer the code for which has been scrutinized
> for many, many years
I think you're mistaken here. It's my understanding that Julian wrote
FF from scratch.
This is from the FF manual:
"FlashFiler's strength builds on the heritage of B-Tree Filer,
TurboPower's popular database engine for Pascal and C++. Like B-Tree
Filer, FlashFiler stores data in a high speed, proprietary format.
However, FlashFiler goes well beyond the B-Tree Filer capabilities to
include many new features."
That quote is a bit fuzzy but it's the only thing I could quickly put
my hands on. I own both BTF and FF and I'm not aware of any code
that's the same between them.
Robert Schiller
Harald Fjerdingstad
> Ole Willy Tuv wrote in message <8od81d$ee...@bornews.borland.com>...
> NativeDB 1.86 TAsaSQL - Time: 23273 ms - 200000 records processed
> Total time: 23591 ms
> Total time: 29145 ms
According to Mr. Ole Willy Tuv's results and observing the
extensive traverse test, I can clearly see that the WINNER IS......
NativeDB's TAsaSQL on Sybase SQL Anywhere
traversing 200,000 rows in 23591 msecs.
Second best DBISAM with 29145 msecs.
<g>
- Harald Fjerdingstad
Author of NativeDB at www.nativedb.com
Tim Young
<< According to Mr. Ole Willy Tuv's results and observing the extensive
traverse test, I can clearly see that the WINNER IS...... >>
I really like your sense of humor, it's been sorely missing in this thread.
<G>
Dean Hill
Eryk wrote:
> > There are many contributions in FF the source code of
> > which were donated to Turbopower by FF users. They could
> > only do this because the source was available.
>
> They are mostly enhancements rather than bug fixes though ...fair?
I have been using FlashFiler for quite a substantial period of time. I
know this has not been the case. One user modified and repaired quite a
bit of code on his own in order to make the engine thread safe. The
quality of his work was such that someone from another company asked if
he
wanted to beta test their product. There have been numerous other
examples of this over time. Before patches are made available, a subset
of the fixes are made availble to users so that they may implement them
for themselves. I personally have used the source of FlashFiler to pick
up bugs in my own source code.
> > Many bugfixes have also been contributed by FF users.
>
> Quite possibly but I'm convinced Julian would have nailed them himself
> anyway. I'm sure source code bug reports with suggested fixes make his job a
> bit easier, but I doubt it impacts significantly on the end result.
There are also situations where an error only occurs on a clients
setup. In these cases it can be almost imposible for someone like
Julian to detect the bug.
> > You can't see any benefits gained from that? Seriously?
>
> I can see the benefits in the enhancement arena and possibly making the
> developer's job a little easier but I remain unconvinced about the bottom
> line impact on overall product stability.
See above.
> > http://www.mysql.com/information/benchmarks.html
> >
> > The MySQL people reckon THEIR engine is better based on
> > THEIR benchmarks
>
> I don't doubt it. I've never bothered to look but I'd assume MSFT benchmarks
> put SQL Server above Oracle and Oracle Corp. benchmarks do precisely the
> opposite. That's why I'm opposed to allowing *any* engine specific tuning
> ....it often makes it possible to massage the figures.
Paul was not talking about engine specific tuning. He was using freely
available (and some of these enhancements have been included in the
product) add ons. Paul has introduced a new protocol which bypasses the
windows protocols. Lets say that only TCP/IP was supported by default
in a product. If an IPX protocol was added in a bonus section, should
someone be prohibited from using this in any tests?
Dean
Eryk
> > They are mostly enhancements rather than bug fixes though ...fair?
>
> I have been using FlashFiler for quite a substantial period of time. I
> know this has not been the case. One user modified and repaired quite a
> bit of code on his own in order to make the engine thread safe. The
Unless the engine was supposed to be thread safe in the first place then I'd
have to classify this as an enhancement rather than a bug fix and, as you
saw, I'm not disputing the enhancement side of things.
> There are also situations where an error only occurs on a clients
> setup. In these cases it can be almost imposible for someone like
> Julian to detect the bug.
There are situations where it is difficult but I've yet to see one which
could not be traced other than those which stem from operating system level
problems and none of us have the source code to that.
> Paul was not talking about engine specific tuning. He was using freely
> available (and some of these enhancements have been included in the
> product) add ons. Paul has introduced a new protocol which bypasses the
> windows protocols. Lets say that only TCP/IP was supported by default
> in a product. If an IPX protocol was added in a bonus section, should
> someone be prohibited from using this in any tests?
Not so long as the IPX protocol was an officially supported feature of the
product, otherwise I don't think it would be appropriate to include it
(incidentally, isn't this a moot point? FlashFiler already supports IPX
doesn't it?).
Eryk
--
BF Deleen
Motyer has been fair, open, scientific and professional in his assessments,
analyses and comments.
Stick to the real issues Mr. Eryk and leave out the strange and irrational
conclusions.
It is all here for everyone to read and form their own opinions.
While products are one thing, I am glad for the opportunity to know more of
the people I may deal with.
"Eryk" <er...@eryk.spanner.demon.co.uk> wrote in message
news:39ab9432_2@dnews...
> Paul,
>
> > You are mis-interpreting what I write, jumping to
> > strange conclusions and then accusing me falsely
> > and being very nasty about it
>
> I reviewed what you wrote several times because I didn't believe you could
> be headed down that route. That's why we specifically asked for
> clarification:
>
> > << Flash Filer was released in early 1997 with full source so it's
pretty
> > well debugged by now. >>
> >
> > I'm not sure where you're headed with this
> >Just stating facts. The implication is obvious.
>
> ...and you declined to provide any. The only remaining explanation is that
> it's a random statement of fact with no relevance to this branch of the
> conversation and it didn't seem logical to draw that conclusion.
>
> > I don't wish to persist or respond at this level
>
> My reaction precisely.
>
> > Huh? Where do you get that from? This is just plain wrong.
> > Re-read what I wrote and maybe you'll see I was writing
> > about FF and its code. Read what else is on that
> > paragraph: it's about FF
>
David Marcus
> I disagree. Access to source code may make some bug reports more detailed
> (though I see no evidence of it personally) but I've yet to encounter a bug
> which could only be detected via source code (it would be debateable whether
> such an issue really *was* a bug).
>
> > which were donated to Turbopower by FF users. They could
> > only do this because the source was available.
>
>
>
> Quite possibly but I'm convinced Julian would have nailed them himself
> anyway. I'm sure source code bug reports with suggested fixes make his job a
> bit easier, but I doubt it impacts significantly on the end result.
I disagree. It is much easier to figure out that something *is* a bug
when you have access to the source code. This allows you to see what the
code is trying to do. Otherwise, you might just assume that the behavior
is WAD, but poorly documented.
On the other hand, letting customers see your source code means that they
can judge for themselves the quality of the coders!
--
David Marcus
David Marcus
> I think you're mistaken here. It's my understanding that Julian wrote
> FF from scratch.
I also think Julian wrote FF from scratch. And, Julian didn't write B-
Tree Filer. TurboPower bought it from a German company. Julian did become
the primary maintainer of B-Tree Filer.
--
David Marcus
Tim Young
<< What becomes clearer and clearer for anyone who reads all this is that
Paul Motyer has been fair, open, scientific and professional in his
assessments, analyses and comments. >>
It's not so very clear to others like myself - Paul has continuously implied
things and then refused to comment on what he really means. I would suspect
that he's simply trying to avoid the appearance of being less than impartial
about his comments regarding FlashFiler and DBISAM, which I find a bit
disingenuous. The bottom line is that DBISAM users weren't the only
respondents to the original post, and Paul specifically queried someone
regarding the speed issue and DBISAM. He brought the issue to the
forefront and seemed determined to prove that the statement about speed was
incorrect (which it was, but not in the manner that he is trying to prove),
thus here we are.
--
Tim Young
Tim Young
<< I disagree. It is much easier to figure out that something *is* a bug
when you have access to the source code. This allows you to see what the
code is trying to do. Otherwise, you might just assume that the behavior is
WAD, but poorly documented.
On the other hand, letting customers see your source code means that they
can judge for themselves the quality of the coders! >>
I think we are digressing here - basically Paul made a statement to the
effect that:
Source Code Availability = More Stable Product
And this is simply not true.
Tim Young
<< In your mind only. >>
Great, then why don't you clear things up completely by answering my last
email with responses to my questions instead of grumbling about how I'm
attacking and insulting you ?
<< What? Can you imagine anyone reading this thread who thinks I'm
impartial? >>
Yes, in fact - the gentleman I replied to.
<< for those for whom English is not their native language, this is a slur
on my character, it means "sly, dishonest, cunning, not open, not frank,
insincere" - and I take offence to this. >>
It means not being open about the fact that you really wouldn't give DBISAM
any credit even if it were faster. All I've heard to everything I've said
is "but":
Situation - The benchmarks clearly show that we're quite fast when compared
to other database engines
Response - Yes, but they certainly won't hold up under multi-user conditions
Situation - The DBISAM / FlashFiler insert test had DBISAM coming out ahead
with both products in an "out-of-the-box" condition
Response - Yes, but I've got this add-on that will fix that
etc.
<< and so? Maybe when I wrote that I don't object to posts about
alternatives I meant it >>
Well you sure show it in an odd way.
<< Yeah, Ole's benchmark is flawed now, earlier you said this:
"As for the tests being flawed, Ole did an excellent job on the insert
benchmark that he gave to Paul and it was not flawed in any way."
I can understand you trying to put a positive spin on things but I think
that personal attacks are unbecoming. >>
Read that statement again - what I said was "not in the manner that he is
trying to prove". Our own benchmarks on our web site show that we're not
the fastest engine around all of the time. You were trying to prove that
DBISAM was not faster than FlashFiler and, therefore, the test that Ole was
conducting was flawed because it showed otherwise. The test was not
flawed - you introduced an add-on into the equation that does not represent
the product supported and distributed by TurboPower. I can introduce tweaks
into DBISAM that will get the insert speed up to a phenomenal rate (we do it
for result sets), however it means very little in the overall scheme of
things and does not represent the product that is in the customer's hands
when they receive it from us.
<< You find double meanings in much of what I write, you insult me, Eryk
does too. It's most unpleasant I can assure you and totally unnecessary >>
I'm not finding any double meanings at all - they're there and you just
simply refuse to clarify them. If you want to say that you think DBISAM
stinks and that it's an unstable piece of crap compared to FlashFiler then
go ahead, just be prepared to back it up with something other than "the
source code is available for FlashFiler, hence....".
I can assure you of one thing - the first day FF2 is released it will
definitely go right up on our SQL benchmarks page along with everyone else
and we'll all finally see where the chips fall.
mdowney
say i have a workstation that is using TCP/IP or IPX/SPX...and i want to see
if files on the computer with the flash filer are newer than the workstation
.
Is there any way to do this without physically mapping a drive ??
Thanks,
mike
"Paul Motyer" <s...@the.sig.com> wrote in message news:39ac6350_2@dnews...
> "Richard Wilson" wrote
>
> > Re FF
> > With TCP/IP if you know the TCP/IP address then you do NOT need to know
> the
> > path
> > Yes you have to know the ServerName and TCP/IP address - for me that is
a
> > plus as it provides a level of security
>
> Actually, with FF, if UDP broadcasts can get through between Client and
> Server then
> you don't even need to know the servername, IP address or Path
>
> The Client can automatically find the server via UDP broadcasts. The
server
> can
> (optionally) query the Client for a password
>
> This makes installation pretty simple
> --
> Paul Motyer
>
>
Paul Motyer
> I reviewed what you wrote several times because I
> didn't believe you could be headed down that route.
And there's the rub: after drawing your conclusions you
just weighed straight in, flamethrower to the fore. No:
"Whoa there! Am I reading this right? Are you implying ..."
Did you review the WHOLE THREAD?
The basic question was: How good is FF?
That's the context. I was attempting to elucidate
what I see as one of FF's positives.
> That's why we specifically asked for clarification
> ...and you declined to provide any.
That's BS. Why not read the whole section.
Here's the "implication" if you need to
find implications in what I write:
"The longer the code is available to scrutiny
by all customers the less bugs will remain un-squished.
I'll flesh it out even more:
There are many contributions in FF the source code of
which were donated to Turbopower by FF users. They could
only do this because the source was available.
Many bugfixes have also been contributed by FF users.
You can't see any benefits gained from that? Seriously?
Consider this then:
If the BDE source were available I suggest to you it'd have
been fixed long ago.
Do you get it now?
> > Read what else is on that
> > paragraph: it's about FF
>
> No it's not,
Yes it is:
Just stating facts. The implication is obvious.
I didn't mention that the core engine was based on
B-Tree Filer the code for which has been scrutinized
for many, many years
> InterBase doesn't win any prizes simply for being 'old'.
No, it's not the age it's the robustness, bug fixes and
improvements gained by users examining the code and
contributing. This can now happen with IB because the
code's available
> I'm not surprised. Tuning can have a significant impact
> on the performance of many engines so I'd expect any losing
> vendor (as MySQL was in that test) to suggest improvements.
Yeah, right. Look at this then:
http://www.mysql.com/information/benchmarks.html
The MySQL people reckon THEIR engine is better based on
THEIR benchmarks
> Then this entire issue is one big misunderstanding and I apologise.
I accept.
Eryk, I've reviewed several hundred of your posts
(mainly on the elevatesoft NGs) and you're usually
quite pleasant (as I guess one would be to one's customers).
Why you never gave me the same common courtesy I don't know.
If you interpreted what I wrote in such a way that it
offended you then I apologize because that was never
my intention. I don't hide behind "implications", if
I thought your code was crap I'd say so. If I thought
it excellent I'd say that, too.
---
Paul Motyer
Eryk
> I disagree. It is much easier to figure out that something *is* a bug
> when you have access to the source code. This allows you to see what the
> code is trying to do. Otherwise, you might just assume that the behavior
> is WAD, but poorly documented.
As I said, my experience differs. I have yet to see a bug report on which
source code review had any bearing.
> On the other hand, letting customers see your source code means that they
> can judge for themselves the quality of the coders!
Just so we don't get off on an irrelevant sidetrack, you are aware that
*both* FlashFiler and DBISAM ship with full source code? This discussion is
not about whether source code is available or not, it's about what (if any)
practical difference it makes to product stability.
Richard Wilson
For single user apps DBISAM is very simple and pretty reliable.
For multi user apps or where data reliability is top priority I go for FF
because it is Client Server and I have found it very reliable in looking
after its data.
I have only had one data problem with FF and that occurred while they were
developing FF1.56, data was not lost but indexes got into trouble, a
restructure fixed it. Now that that problem has been solved FF as far as I
am concerned is back to its wonderful ways - you just do not have to reindex
or pack or anything like that. [I cannot stop hardward failures - so backup
and backup and backup!!]
I have had to do a "repair" on occasions with DBISAM and it works very
well - it is far more reliable with data than Paradox in my opinion and
creates very easy to distribute apps.
I currently do not use SQL so that is not an issue for me - FF wish SQL is
under development.
The two products are different, one is file based and the other
Client/Server.
There are no "per seat" licenses with FF which is a great gain over most
other C/S products
FF has some learning curve particularly relating to learning to connect to
the server [and that can be over ANY TCP/IP connection]
FF parallels Paradox tables very well [not queries] and so it drops into
Delphi very easily, by and large it "thinks" like Paradox, as does DBISAM.
This makes both of them easier to use than Interbase.
The FF Server is compact [still fits on a floppy] and generally does not
load up the server - and I am hearing that from those who maintain the
servers!
If you have 5 to 50 users then I would not hesitate to go the Client Server
route and personally I would go for Flash Filer.
Both FF and DBISAM have excellent support and I wish both of them well
Richard Wilson
One Tree Hill, South Australia
"Mark" <mkn...@mgh.org> wrote in message news:39a6c443$1_1@dnews...
> Hi. I am the originator. My needs vary from fairly simple single-user
apps
> to fairly complex multi-user apps ranging from 5 to 50 concurrent users.
> These are primarily medical-research related applications, and they
> generally see a lot of use, although typically not a lot of records are
> added during a given day(dozens or hundreds per day, rather than thousands
> or more). I have used Paradox tables, almost exclusively, with very
little
> trouble, but distribution and configuration of the BDE is always
> problematic, and I'm always waiting for the gotchas I'm always hearing
about
> with Pdox tables. Further, I would like to use one DB platform if
possible
> for both single and multi-user C/S apps, simply to minimize the number of
> learning curves I must climb. In the fairly short term, many of my users
> will need IP access to this data, so I need something that will work
> properly over IP. How do FF and DBISAM compare in this regard? How about
> security? Do either of these create a db object that hides the db
> tables/files from simple file system browsing? Raw speed is important,
but
> stability and security are more critical to my bread and butter.
>
> Thanks for all of the comments to this point. Mark.
Richard Wilson
I find this protocol very reliable
Richard Wilson
"Brion L. Webster" <brion....@nospam.ci.fresno.ca.us> wrote in message
news:8o6skg$h3...@bornews.borland.com...
> I'd second IB6 w/IBX (all free so far), but add on ASTA (www.astatech.com)
for
> the access over IP (not free). It certainly makes things easier for
distributed
> data access.
>
> -Brion
>
>
Richard Wilson
> Hi Gregor, you got me interested there!
>
> Could you tell me how they will install the client exe without major fuss
> about knowing what is the name of the server etc?
>
> I am actually going to use Interbase, but since with Interbase you need to
> specify the server name *and* the database including its *path* I think
it's
> a potential to be a "complicated" process.
>
> I would appreciate if you could give me a hint on how to do this easily...
> (hopefully not relying on tcp/ip as IB can be installed on pure netbeui /
> ipx/spx)
>
My experiences of NetBeui are pretty awful!
FF does support IPX/SPX and there are people using it [I stay with the
safety of TCP/IP]
Richard W
Richard Wilson
With TCP/IP if you know the TCP/IP address then you do NOT need to know the
path
Yes you have to know the ServerName and TCP/IP address - for me that is a
plus as it provides a level of security
Works very well
Richard Wilson
"Jimmy Harlindong" <ji...@nospam.com> wrote in message
news:8ogcpe$dt...@bornews.borland.com...
> Hi Gregor, you got me interested there!
>
> Could you tell me how they will install the client exe without major fuss
> about knowing what is the name of the server etc?
>
> I am actually going to use Interbase, but since with Interbase you need to
> specify the server name *and* the database including its *path* I think
it's
> a potential to be a "complicated" process.
>
> I would appreciate if you could give me a hint on how to do this easily...
> (hopefully not relying on tcp/ip as IB can be installed on pure netbeui /
> ipx/spx)
>
> TIA
>
>
> > Please remember that FlashFiler needen't any sharable directories.
Client
> > apps communicate with FF server via transport layer (TCP/IP or IPX/SPX).
> One
> > of our application runs in NetWare 5 networks on NT workstations. And
> > FlashFiler server is stuck on Windows Terminal Edition/Metaframe server.
> > None of clients knows where the server and databases are located in the
> > network :). When a new person wants to access the database, an
> administrator
> > installs only client EXE on the workstation and sets the protocol type.
> >
> > ----------
> > Grzegorz Wiktorowski
> > OiOK
> >
> >
>
>
Paul Motyer
> I think we are digressing here - basically Paul made a statement to the
> effect that:
>
> Source Code Availability = More Stable Product
>
> And this is simply not true.
Again we disagree.
In fact, maybe it's because you believe that, that you have wrongly
interpreted what I've said to mean something totally different to
what I wrote. I really am incredulous that you don't agree.
Why do so many want the Source - so much so that they
will pay more? Just so they can recompile when a new version
of their compiler comes out?
Who believes that the VCL source being available hasn't helped
Borland/Inprise fix reported bugs? The longer that's it's available
the greater the benefit
I am certain that the FF source being available has meant the FF
codebase is now more stable. Obviously, though, "this is simply
not true"
--
Paul Motyer
Paul Motyer
> Eryk wasn't flaming you, so don't get your panties in a bunch
Hmm... now your getting silly
> the problem he (and I) are having with your messages is
> that you insist on making broad statements about how FF is better
Where did I say that?
> ... and in the process use thinly-disguised
> comments about FF to impune our integrity
You like interpreting what I write in a funny manner
> (yes, your comments about our benchmarks basically dance
> around the issue of whether we slanted the tests
> in our favor)
Crap.
> Eryk and I both take this stuff very personally
Indeed, and not always rationally.
Why not just start attacking me, "personally", too
--
Paul Motyer
Paul Motyer
> It's not so very clear to others like myself - Paul has continuously
> implied things
In your mind only.
> and then refused to comment on what he really means.
So, I don't mean just what I write?
> I would suspect
> that he's simply trying to avoid the appearance of being less than
> impartial about his comments regarding FlashFiler and DBISAM,
What? Can you imagine anyone reading this thread who thinks
I'm impartial? I've been hiding the fact I think FF is a seriously
good product and I'd recommend it?
> ... which I find a bit disingenuous.
for those for whom English is not their native language, this is a slur on
my character, it means "sly, dishonest, cunning, not open,
not frank, insincere" - and I take offence to this.
> The bottom line is that DBISAM users weren't the only
> respondents to the original post,
and so? Maybe when I wrote that I don't object to posts about
alternatives I meant it
> and Paul specifically queried someone
> regarding the speed issue and DBISAM.
Here's what Ole wrote (referring to DBISAM):
"- The fastest engine around"
and:
"I can't see where you possible could find better speed elsewhere."
and (referring to FF):
"I did not time it, but appending the 200000 records to the
FF table took some 15-20 minutes or so, in any case much
longer than the 2.75 minutes with
DBISAM 2.03 on my Windows 98 system."
Now, believing that to be false, I should do what? Bite my tongue?
Here's what Ole posted AFTER I sent him FF Exe's using his
benchmark referring to FF Single User:
"I can confirm that the append test flies even faster on my system,
200000 records appended in 37 seconds here."
and:
"Well, I compiled a TDBISAMTable version of the project and
opened the table excusivly. The append test executed in 100 seconds."
and (referring to FF Multi-user):
"Standard mode - 362257 ms
Using batches - 74237 ms"
Here's a summary (run all on Ole's computer):
TDBISAMTable (exclusive true): 100 seconds
FF Single User: 37 seconds
TDBISAMTable Multi-User: 164.292 seconds
FF Multi-User: 74.237 seconds (batched)
FF Multi-User: 362.257 seconds (not batched)
All a far cry from "some 15-20 minutes or so"
"- The fastest engine around" - not quite
You really believe I should just sit and bite my tongue?
> He brought the issue to the
> forefront and seemed determined to prove that the statement
> about speed was incorrect (which it was, but not in the manner
> that he is trying to prove),
Yeah, Ole's benchmark is flawed now, earlier you said this:
"As for the tests being flawed, Ole did an excellent job on the insert
benchmark that he gave to Paul and it was not flawed in any way."
I can understand you trying to put a positive spin on things but I think
that personal attacks are unbecoming.
You find double meanings in much of what I write, you insult me,
Eryk does too. It's most unpleasant I can assure you and totally
unnecessary
--
Paul Motyer
Paul Motyer
> Re FF
> With TCP/IP if you know the TCP/IP address then you do NOT need to know
the
> path
> Yes you have to know the ServerName and TCP/IP address - for me that is a
> plus as it provides a level of security
Actually, with FF, if UDP broadcasts can get through between Client and
Eldon Yeung
> I disagree. I've never recompiled FF server. We distribute one
installation
> executable including FF server (out of box) and client apps. Users check
> what they want to install. When everything runs only upgrades of client
apps
> are distributed and re-installed.
>
I am not saying that developing FF application is difficult. What I mean is
that we need to compile our application into two executables for deployment,
one for client/server environment and the other for single user. Some of
our customers are working on standalone machines.
>
> Again I don't agree. We include FF server's scripts file to set it's
> options. Without scripts files you have to choose the protocol type + two
> checboxes. I don't think it's complicated.
>
In fact, some of our customers are working on a small Novell/Linux network
and don't get any extra Windows station to house the server. A F/S
application may be the only choice for them. Again, I am not saying setting
up FF server is complicated, but no server/protocol setup and configuration
is required for F/S application.
> None of clients knows where the server and databases are located in the
> network :). When a new person wants to access the database, an
administrator
> installs only client EXE on the workstation and sets the protocol type.
>
I totally agree with you on a better security control for C/S application,
and F/S application is impossible to overcome the weakness in protecting
data.
Eldon Yeung
Eryk
> Why do so many want the Source - so much so that they
> will pay more? Just so they can recompile when a new version
> of their compiler comes out?
Mostly that and sometimes because there is a corporate policy compelling
them to do so. We both know that many Delphi users don't pay the slightest
attention to the VCL source code and the same applies to the 3rd party
products they purchase.
> Who believes that the VCL source being available hasn't helped
> Borland/Inprise fix reported bugs? The longer that's it's available
> the greater the benefit
How many people do you suppose actually use the PAS version of the VCL
compared with the default DCU version?
> I am certain that the FF source being available has meant the FF
> codebase is now more stable. Obviously, though, "this is simply
> not true"
But that's what you've been arguing! FlashFiler has had source availability
from day one, DBISAM has not, ergo DBISAM must be buggier and less stable
than FlashFiler ...otherwise your argument is self contradictory. Note that
I'm not disagreeing with you about this, FlashFiler's bug list may well be
shorter than DBISAM's ....I just wish you come clean and *say* it instead
of dancing around the issue.
Ole Willy Tuv
I'm not a native English speaker, so please excuse my poor English.
I believe your quotes to my posts have been taken totally out of context:
> Here's what Ole wrote (referring to DBISAM):
>
> "- The fastest engine around"
This statement is from my first post responding to Mark where I recommended
him to check out DBISAM if he also wanted SQL functionality.
Why did I respond? Because a previous response from David Marcus stated that
FF didn't have SQL. Why did I recommend DBISAM. Because I'm a satisfied
DBISAM user who has experienced the excellence of the product and therefore
think it's worth being recommended to others.
I made a few remarks to make my point why I think DBISAM is superior:
- Compiles into the exe with a small footprint
- No additional deployment
- Table and Query TDataset descendants
- Feature rich SQL
- The fastest engine around
- Excellent support
If you see my remark about the 'fastest engine around' in context, it's only
one of IMO several benefits DBISAM is offering. This remark was not solely
based on my own benchmarks, but as much on the comprehensive SQL tests made
by Elevate and published on their web-site.
I agree that it's silly to make such a 'bold' statement. But I believe it
still stands if you take the overall performance of the engine into account.
I had nothing against a quick benchmark between DBISAM and FF based on my
insert and traversal tests. As you have mentioned yourself, these tests
don't say to much, and I agree to that. We were not able to test the real
meat, SQL performance because FF does not have this functionality. You have
got my test application and know that one of my tests is a 10-ways join of
large tables. When FF is able to do this, we could certainly do a new
comparison.
In fact, the SQL functionality is the main reason why I responded to Mark.
> "I did not time it, but appending the 200000 records to the
> FF table took some 15-20 minutes or so, in any case much
> longer than the 2.75 minutes with
> DBISAM 2.03 on my Windows 98 system."
>
> Here's what Ole posted AFTER I sent him FF Exe's using his
> benchmark referring to FF Single User:
>
> "I can confirm that the append test flies even faster on my system,
> 200000 records appended in 37 seconds here."
This is taken totally out of context and IMO unserious both to me and other
readers of this thread. You know very well that the first timing was not at
all a benchmark done with your FF project. What I did was to download a demo
application from TurboPower since they don't publish a trial version of FF.
I imported an ASCII version of my 200000 record test table into the FF demo
app and this operation took 15-20 minutes. Later I got your speciallly tuned
single-user version which was quite impressive in speed. Being aware of this
fact, I asked you to make a regular multi-user version based on my DBISAM
test project. The speed of this version was 362 secs in standard mode and 74
secs in batch mode.
> You really believe I should just sit and bite my tongue?
I really think you should, instead of producing such nonsense as above.
Regards
Ole Willy Tuv