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.