Compare Elevate's DBISAM to Extended Systems: Advantage Database
Tom
server.
We do a lot with TTables on forms, and SQL. No referential integrity.
We're considering jumping to either DBISAM or Advantage.
I've downloaded the Advantage package and I was pleased at how easy I was
able to port a relatively small program to their platform. And of course
it's refreshing to use a tool that is more modern, gives more clear error
messages on SQL syntax errors, and could be used for client-server apps if
we choose.
Is there anyone here who has experience or comparisons of both the DBISAM
and Advantage products and companies? It's so seldom that we make such
subtantial platform decisions, that we're anxious not to jump to a company
which might not have the resources or staying power...
Tom
Connie McBride
Difference #1 - Advantage C/S version has true record locking during
transaction processes. DBISAM locks the entire table or the entire database
during transactions.
Difference #2 - Price tag. DBISAM is royalty-free, so there is no
additional costs to your customers.
Difference #3 - DBISAM has no external DLL's to use, it's embedded. With
Advantage, you have to maintain the DLL's, and there is a separate setup for
the databse engine
Difference #4 - Advantage is very fast, even if you are accessing across a
network in local access mode. DBISAM slows to a crawl, because, like
Paradox, it retrieves all the data before running the query, filter, etc.
With DBISAM, this is fixed if you use the C/S version. With Advantage, you
can't run SQLs in local mode.
Both have an external program to run in C/S version
"Tom" <no...@none.com> wrote in message
news:431f...@newsgroups.borland.com...
Shane Stump
Regards,
Shane
"Tom" <no...@none.com> wrote in message
news:431f...@newsgroups.borland.com...
Tim Sullivan
This is very incorrect. The only difference between the Advantage Local
Server and Advantage Database Server is that transactions are ignored in the
local server. Other than that they're equal in functionality.
--
Tim Sullivan
Unlimited Intelligence Limited
http://www.uil.net
Matthew Jones
> Paradox, it retrieves all the data before running the query, filter,
> etc.
Not if you have indexes appropriately created surely?
/Matthew Jones/
Pierre Demers
> Server and Advantage Database Server is that transactions are ignored in
the
> local server. Other than that they're equal in functionality.
True
Pierre
Pierre Demers
> Is there anyone here who has experience or comparisons of both the DBISAM
> and Advantage products and companies? It's so seldom that we make such
> subtantial platform decisions, that we're anxious not to jump to a company
> which might not have the resources or staying power...
You can't really compare products or company. They are in two different
world. It really depends on what type of application you have. Basically yes
they are two database system, that's where it ends. They are both good. I
have used Advantage and loved it. I left them because of the pricing scheme
on their servers. I now use nexus, although not as mature as Advantage, I am
confident that they will improve the version 2 in the next release or so. I
know DBISAM is a good solution also, you really have to try them all and
choose from there. You really can't go wrong with either choices.
HTH
Pierre
Herbert Sitz
news:memo.2005090...@nothanks.nothanks.co.uk...
Right, if indexes are available and query is optimized to use them then some
index pages may be only data that gets transferred, other than records
responsive to query. Same as any other fileserver database, including the
Advantage Local Database.
Note that DBISAM includes c/s functionality in the basic version that
includes royalty free deployment for a few hundred bucks. To get c/s
version with Advantage you will have to pay out on order of $1k or $2k per
server (I think). Though on the other hand the local version of Advantage
is free, but doesn't include transaction functionality, while both local and
c/s DBISAM versions allow for transactions.
Neither DBISAM version has referential integrity, which is one of the main
things that caused me to move from DBISAM to NexusDB. Advantage simply
wasn't an option for me. I couldn't use the Advantage Local Database, and
because of the number of databases I want to deploy Advantage server fees
would have ended up costing potentially hundreds or thousands of times as
much as NexusDB's single unlimited deployment license.
-- Herbert Sitz
Mark
http://www.datainfosoft.com/fsql/
or at Open Source Firebird Database server
http://www.firebirdsql.com
Hi!
--
Mark
Danijel Tkalcec (RealThinClient)
Tom
Descendant that will allow our current TTables and TQueries (hopefully with
minor syntax differences) to work?
"Connie McBride" <cny8...@centurytel.net> wrote in message
Herbert Sitz
> Any experience porting a BDE app to DBISAM? Does it come with a TDataSet
> Descendant that will allow our current TTables and TQueries (hopefully
with
> minor syntax differences) to work?
>
DBISAM, Nexus, Advantage are all current incarnations of databases that
originated as BDE-replacements. They've gone far beyond that now, but all
of them retain their TDataset descendants that are geared towards making it
simple to convert BDE apps. Not sure if there are niggling details between
them that might make one a little bit easier than another. It should be
quite easy to port a BDE app to any of them.
-- Herbert Sitz
Herbert Sitz
>
>> It's so seldom that we make such
> subtantial platform decisions, that we're anxious not to jump to a company
> which might not have the resources or staying power...
>
> Tom
>
fyi, Extended Systems has recently been acquired by Sybase, which of course
already has a midrange/highend db server of its own. I think a lot of
Advantage customers are wondering what's going to happen to Advantage now..
. .
http://www.bsdg.org/2005/08/sybase-to-assimilate-extended-systems.shtml
-- Herbert Sitz
Hannes Danzl[NDD]
> Take a look at the OpenSource (delphi lang) fssql database
> http://www.datainfosoft.com/fsql/
Which is an extended FlashFiler - didn't know that someone maintains it still.
Great!
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm
Matthew Jones
IIRC, this is coming in the next version due later this year. But the
point about per-server fees reminds me one of the nice things about these
sorts of tools. Just because you don't need to pay the component provider
(database or reporting tool) doesn't mean you can't charge the end user.
It does mean you can charge less than the competition, but it is more
money in your pocket if you choose.
/Matthew Jones/
Connie McBride
"Tim Sullivan" <t...@NO.SPAM.uil.FOR.ME.net> wrote in message
news:431f321b$1...@newsgroups.borland.com...
Connie McBride
I have it verified from their tech.
When in local mode, across the network, it retrieves all the data before
applying queries and filters.
"Matthew Jones" <mat...@matthewdelme-jones.delme.com> wrote in message
news:memo.2005090...@nothanks.nothanks.co.uk...
Connie McBride
operating system for file locking, which locks down the entire table or
database. Trying to do a transaction like that just isn't working for me
(imagine 50 people in a table, then it gets locked down for a transaction).
I have had to do without because of that.
"Herbert Sitz" <hs...@nwlink.com> wrote in message
news:431f...@newsgroups.borland.com...
Herbert Sitz
> No.
> I have it verified from their tech.
> When in local mode, across the network, it retrieves all the data before
> applying queries and filters.
>
You've got something lost in the translation.
Yes, a filter will be applied and processed locally.
But the query itself, i.e., the SQL that is executed in a TQuery descendant,
will make use of indexes if they are available, and in this case it is only
the index data and responsive records that gets transferred, not all records
in the table. This is the case for every fileserver database that I'm aware
of, at least every one that makes proper use of indexes.
Of course, if your query is just "Select * from tablename' then all records
will be transferred. But if your sql is 'Select * from tablename where id =
56' then the only data that gets transferred is a tiny amount of index data
and the single responsive record.
-- Herbert Sitz
Herbert Sitz
> Yes DBISAM does allow for transactions. Problem is that it uses the
> operating system for file locking, which locks down the entire table or
> database. Trying to do a transaction like that just isn't working for me
> (imagine 50 people in a table, then it gets locked down for a
transaction).
> I have had to do without because of that.
>
Locking of the entire table (which doesn't necesarily go hand in hand with
file locking in db's other than DBISAM) can actually be much more efficient
than record locking. It does necessitate a different way of application
coding, since you will want to code things so that all transactions are
short and sweet, lasting only a fraction of a second.
Lots of people who are used to coding when there are db record locks will
code so that a transaction gets started and records get locked as soon as a
user touches a record, then transaction is completed only seconds or minutes
later when user commits changes. You can get away with this if your db
supports record level locking, but it's not the most efficient way of doing
things. IMO, it's better to structure app so that transactions are begun
and committed only when user commits edits, whether your db supports
record-level locking or not.
There is extra-db overhead involved in record-level locking. As an example,
notice that MS SQL Server supports record-level locking but is set up so
that the locks will "escalate" to table level if they become a performance
drag.
-- Herbert Sitz
Tõnis Argus
Porting from BDE is almost easy. You can search in DBISAM newgroups,
there are some posts to read. DBISAM uses more indexes and when Your
queries can use indexes then there are no problems.
Joe Hendricks
http://www.infoworld.com/article/05/07/29/HNsybaseextended_1.html
Maybe best to wait on Advantage option until SyBase
decides if it is a 'cash cow' or not ...
;-)
--
JoeH
[ write a letter, save a life - http://www.amnesty.org ]
Hannes Danzl[NDD]
> notice that MS SQL Server supports record-level locking but is set up so
> that the locks will "escalate" to table level if they become a performance
> drag.
Most DB engines either use table level locking or use this escalation if the
number of record locks reaches a certain threshold. Maintaining record locks
is very costly and drags performance down quite a bit.
In most cases well designed code using table level locking code will perform
better than record locking.
Connie McBride
longer to retrieve the data across the network in local mode that it does to
retreive the same data using the client server version.
That indicates that the data is transferred before applying the query. When
I asked about it, it was confirmed.