ComponentAce are pirates?
"peter"_nospam.pls
Hi!
I downloaded an Absolute DB from ComponentAce to evaluate some time ago.
I tried it in my project and I was going buy it as the product is good and support guys answered me quickly on all the questions I had.
But recently I found an Accuracer Database of the AidAim Software which appeared to be very similar to the AbsoluteDB.
I decided to learn what is the relationship between ComponentAce and Aidaim and why the databases look so much alike.
I asked ComponentAce and AidAim and I got the replies which I copied below.
Now I see that AidAim and ComponentAce are a competing companies.
From AidAim reply I got an impression that ComponentAce illegally uses AidAim's database technologies.
I got only positive response and help from ComponentAce, so it is hard for me to believe. Besides I see that AidAim mail is very aggressive and biassed.
But I don't want to deal with a pirates, so I'd love to know the official positions of the ComponentAce and AidAim
on this issue here and I ask them to comment the mails of each other.
Best wishes,
Peter
Reply from ComponentAce:
> Hello,
>
> First I would like to thank you for your question.
> ComponentAce and AidAim are independent companies.
> ComponentAce team worked with AidAim on many database projects,
> including EasyTable and SQLMemTable.
> ComponentAce has the rights on many database technologies and materials
> created by our people and AidAim people till September 2003 at AidAim.
> ComponentAce used and enhanced these technologies and developed the Absolute Database.
> Let me tell you some words about it.
> Absolute, EasyTable and Accuracer have significant differences.
> I will list some of them:
>
> 1) I/O Speed
> Absolute Database is designed to be fast on 1000 records and on
> 10'000'000 records. It has scalable architecture, whereas EasyTable
> becomes very slow with large number of records. And contrary to the
> Accuracer, Absolute Database has a single-user edition specially
> optimized to achieve high performance there.
>
> 2) SQL speed
> EasyTable's SQL engine cannot use indexes for WHERE SQL conditions.
> Absolute Database has sophisticated searching and filtering engine and
> always use indexes when it is possible and the speed of query
> execution by Absolute Database is typically much higher.
>
> 3) SQL functionality
> Absolute Database has very wide support of SQL functions, including
> support of correlated and non-correlated subqueries. EasyTable and
> Accuracer don't have support for correlated subqueries.
>
> 4) Convenience
> Absolute Database allows to have default values for fields and min,max restrictions,
> to display progress of potentially lengthy operations with cancel option,
> to specify different compression options for each BLOB field, to
> export table to SQL, EasyTable doesn't.
>
> 5) Scalability
> The database file of Absolute Database Multi-User Edition have the same format as in
> single-user edition, so you can easily switch to the multi-user if
> you will need to. Of course we will provide special upgrade price for
> upgrade from single-user edition to multi-user.
>
> 6) Reliability
> Absolute Database auto-detects database corruption caused by power
> loss during writing to database file and can automatically repair the
> database, neither EasyTable nor Accuracer have such possibility.
>
> Please feel free to write me if you have any questions.
>
> --
> Best regards,
> Mark Witton mailto:sa...@componentace.com
Reply from AidAim:
> Dear Peter Varan,
>
> Thank you for your interest in our products.
>
> About AidAim and ComponentAce
> -----------------------------
> ComponentAce is not a subsidiary company of AidAim Software LLC.
> Neither AidAim Software LLC, nor anybody of the people who work at
> AidAim has no part in ComponentAce.
>
> ComponentAce was founded by the members of AidAim Software developers
> team. They are just the guys worked at AidAim Software before they
> founded ComponentAce.
>
> ComponentAce is fully independent company and we (at AidAim) cannot
> say why they changed their goals and now develop databases instead of
> focus on the compression products as they said in their press-release.
>
> About database products
> -----------------------
> These guys take part in design and coding of our database products,
> EasyTable and Accuracer, and now they founded their own new company
> and released their own new system, Absolute, which is based on AidAim
> database technologies and includes some features of EasyTable,
> SQLMemTable and Accuracer.
>
> Just some facts for you to be sure who is the leader:
>
> 1. AidAm Software starts on-line sales of the database components with
> EasyTable in January 2001. ComponentAce was founded in September 2003.
> We are 3 years in developing and selling database components they are
> just now starting.
>
> 2. We have 3 database components: EasyTable, SQLMemTbale and
> Accuracer, even Single File System is more similar to database than to
> compression component. They have only compressions components and only
> started sales of AbsoluteDB.
>
> 3. Accuracer was released 10/23/2003 and Absolute was released two
> months late -- do not take into account that it is v.4 now -- they
> release bug-fix versions very often so I do not know what was the
> difference between v.1 and v.2 or between v.3 and v.4.
>
> 4. The first version of Accuracer (October 23, 2003) was multi-user
> version, we developed this product as multi-user database first of
> all. The multi-user version of AbsoluteDB, v.3.00, was released
> January 27, 2004 only, 3 months later. So Absolute is a local,
> single-user database and they just now have implemented multi-user
> superstructure.
>
> 5. Accuracer is the cross-platform database, we have Kylix version and
> have plans to develop .Net provider. I am not sure that Absolute will
> be cross-platform one day in the future -- they do not work to port it
> to Kylix and even have no such plans as I know.
>
> 6. Accuracer is a client-server database now. As I know they have no
> plans to develop client-server version yet.
>
> 7. Accuracer has ODBC Driver. Even our old product, EasyTable, has
> ODBC Driver. Trust me, I know these guys, Absolute will have ODBC
> Driver never, they do not wield such technology.
>
> 8. Some technical differences in brief:
> - Accuracer supports varchar fields while AbsoluteDB does not
> - AbsoluteDB does not allow to create records larger than database
> page size
> - AbsoluteDB uses our old EasyTable's encryption technologies (it does
> not provide encryption by keys and supports smaller set of encryption
> algorithms). Accuracer offers unmatched strong encryption. The
> difference is great like between EasyTable and Accuracer -- you can
> read the following material for details:
> http://www.aidaim.com/articles/Accuracer-EasyTable_features.php
>
> That's why their site and their documentation are a copy of ours in
> some parts.
>
> If you know any advantage of AbsoluteDB in comparison with Accuracer
> just inform me. We'll do the all to exceed it.
>
> Best regards,
> Ray Lahoy
> AidAim Software mailto:sup...@aidaim.com
Reinhold Erlacher [TeamRO]
"Al" <removespam...@iinet.net.au> wrote in message
news:4068...@newsgroups.borland.com...
>
> <Peter nospam.pls> wrote in message
> news:4068342a$1...@newsgroups.borland.com...
> >
> > Hi!
> >
> > But I don't want to deal with a pirates, so I'd love to know the
official
> positions of the ComponentAce and AidAim
> > on this issue here and I ask them to comment the mails of each other.
>
> I gathered from their emails to you that they had stated their position on
> the matter already. Whatever, to be honest I think your private emails
> between the parties should be kept in your inbox and not out here. If you
> had posed the question publicly and asked for comment then fair enough but
> pasting personal emails is a bit rough IMO.
>
>
>
Al
<Peter nospam.pls> wrote in message
news:4068342a$1...@newsgroups.borland.com...
>
> Hi!
>
positions of the ComponentAce and AidAim
> on this issue here and I ask them to comment the mails of each other.
I gathered from their emails to you that they had stated their position on
Andrew Harrison
Peter, I think it was not a good idea to ask such questions here.
Anyway I will answer...
My name is Andrew Harrison, I am vice-president of the ComponentAce LLC.
I was one of the AidAim founders and I worked there since the company foundation.
I left AidAim and now I am working at ComponentAce and I am its part owner.
ComponentAce and AidAim are competitors now.
Peter, I think that you didn't understand AidAim's guy position right,
but anyway we are very surprised to see such mail from AidAim's side.
I have to clarify the situation to stop the speculations which hurt our business.
>> ComponentAce was founded by the members of AidAim Software developers
>> team. They are just the guys worked at AidAim Software before they
>> founded ComponentAce.
It is not the truth, AidAim was splitted.
One half of the owners and developers from AidAim founded the ComponentAce.
ComponentAce has the signed agreement with the AidAim by which all the rights
on CompressionMaster, ZipForge, FlexCompress, Easy Compression Library (VCL, Kylix and ActiveX)
are transferred to the ComponentAce.
ComponentAce started sales, support and further development of
these components since September 15th, 2003 and AidAim stopped selling and supporting them.
On the moment of split we worked on a database system project.
ComponentAce and AidAim have the rights on the technologies and materials of this project.
AidAim used them while developing the Accuracer,
ComponentAce used them while developing the Absolute Database.
So the Absolute Database and the Accuracer have some similarities in
technologies and documentation, but these databases are two different products
which have important architectural and technological differences.
>> ComponentAce is fully independent company and we (at AidAim) cannot
>> say why they changed their goals and now develop databases instead of
>> focus on the compression products as they said in their press-release.
At first we didn't plan to develop database systems, but later
after more close market analysis we decided to use our rights
and to develop a new database system - Absolute Database.
>> These guys take part in design and coding of our database products,
>> EasyTable and Accuracer, and now they founded their own new company
>> and released their own new system, Absolute, which is based on AidAim
>> database technologies and includes some features of EasyTable,
>> SQLMemTable and Accuracer.
ComponentAce has full rights to use these technologies.
The technologies were developed by our team and AidAim people when they worked together.
Since that time ComponentAce team enhanced those technologies
and developed new ones, which are used in the Absolute Database product now.
>> Just some facts for you to be sure who is the leader:
>> 1. AidAm Software starts on-line sales of the database components with
>> EasyTable in January 2001. ComponentAce was founded in September 2003.
>> We are 3 years in developing and selling database components they are
>> just now starting.
Members of ComponentAce team worked at AidAim since their start,
so we have the same more than 3 year experience.
>> 2. We have 3 database components: EasyTable, SQLMemTbale and
>> Accuracer, even Single File System is more similar to database than to
>> compression component. They have only compressions components and only
>> started sales of AbsoluteDB.
Our team worked at AidAim on all database and compression projects till September 2003,
we have highly experienced professionals.
>> 3. Accuracer was released 10/23/2003 and Absolute was released two
>> months late -- do not take into account that it is v.4 now -- they
>> release bug-fix versions very often so I do not know what was the
>> difference between v.1 and v.2 or between v.3 and v.4.
I am glad to see that we are growing so fast
that our competitors cannot even keep track of our progress.
Here is only a brief description of the Absolute Database development major steps:
12/09/2003 v.1.00 Single-user, signle-thread database engine.
12/24/2003 v.2.00 In-memory tables and multi-thread support.
01/27/2004 v.3.00 Multi-user with transactions.
03/05/2004 v.4.00 SQL: correlated and non-correlated subqueries, IN, EXISTS, BatchMove.
We had done a really great job and we are continuing do it.
>> 4. The first version of Accuracer (October 23, 2003) was multi-user
>> version, we developed this product as multi-user database first of
>> all. The multi-user version of AbsoluteDB, v.3.00, was released
>> January 27, 2004 only, 3 months later. So Absolute is a local,
>> single-user database and they just now have implemented multi-user
>> superstructure.
Contrary to Accuracer, Absolute Database was specially optimized for the single-user mode
and only after that we developed also highly optimized multi-user version.
Anyway I would like to mention that Absolute Database has transactions support
in multi-user and single-user mode since the earlier time than AidAim's product.
>> 5. Accuracer is the cross-platform database, we have Kylix version and
>> have plans to develop .Net provider. I am not sure that Absolute will
>> be cross-platform one day in the future -- they do not work to port it
>> to Kylix and even have no such plans as I know.
>> 6. Accuracer is a client-server database now. As I know they have no
>> plans to develop client-server version yet.
Kylix version of Absolute Database is not planned at present time,
but we have plans to support .NET and Client/Server.
>> 7. Accuracer has ODBC Driver. Even our old product, EasyTable, has
>> ODBC Driver. Trust me, I know these guys, Absolute will have ODBC
>> Driver never, they do not wield such technology.
Development of the ODBC Driver for the Absolute Database will be completed soon.
It is expected to be released within the closest 2 weeks.
>> - AbsoluteDB uses our old EasyTable's encryption technologies (it does
>> not provide encryption by keys and supports smaller set of encryption
>> algorithms). Accuracer offers unmatched strong encryption. The
>> difference is great like between EasyTable and Accuracer
It is untruth. Absolute Database doesn't use EasyTable's encryption technologies.
Our team implemented another strong advanced encryption scheme in Absolute Database.
It supports large choice of known strong encryption algorithms: Rijndael 128/256,
BlowFish, TwoFish and others.
It is far from EasyTable's one.
Accuracer has complicated for most users encryption settings
that could be correctly used by crypto-experts only.
Absolute Database is designed to be more easy to use keeping the strong security.
I am not acquainted with the new guy at AidAim - Roy Lahoy
and I don't know why he is trying to discredit our company.
We are waiting for the official explanations from AidAim.
Best regards,
Andrew Harrison,
ComponentAce http://www.componentace.com
Robert Cerny
technologies.
> Our team implemented another strong advanced encryption scheme in Absolute
Database.
> It supports large choice of known strong encryption algorithms: Rijndael
128/256,
> BlowFish, TwoFish and others.
> It is far from EasyTable's one.
> Accuracer has complicated for most users encryption settings
> that could be correctly used by crypto-experts only.
> Absolute Database is designed to be more easy to use keeping the strong
security.
>
Well, Easytable uses DEC, free encryption code by Hagen Reddmann. So it
seems with ADB and Accuracer.
So, ADB does not use EasyTable's encryption, but uses the same (or almost)
encryption code freely available as does Easytable.
Same thing with compression.
It would be stupid to reinvent compression and encryption with so much
freely available code and such claims violate its copyright.
Note that such wars harm you both (companies), if you can't clear things in
private (you obviously didn't on split), you might seek damage recovery in
court.
--
Robert Cerny
DelphiShaman
Ella Perelman
Nice to see that ComponentAce do not try to deny the facts but we have to comment some
inaccuracies, ones are intentional or not.
>Members of ComponentAce team worked at AidAim since their start,
>so we have the same more than 3 year experience.
Only one man at ComponentAce worked at AidAim Software about 3 years -- you are, Andrew Harrison,
vice-president of the ComponentAce LLC, and nobody longer.
>Our team worked at AidAim on all database and compression projects till September 2003,
>we have highly experienced professionals.
See the comment above. Only one man worked at AidAim Software about 3 years, vice-president of the
ComponentAce LLC.
>I am glad to see that we are growing so fast
>that our competitors cannot even keep track of our progress.
>Here is only a brief description of the Absolute Database development major steps:
>12/09/2003 v.1.00 Single-user, signle-thread database engine.
>12/24/2003 v.2.00 In-memory tables and multi-thread support.
>01/27/2004 v.3.00 Multi-user with transactions.
>03/05/2004 v.4.00 SQL: correlated and non-correlated subqueries, IN, EXISTS, BatchMove.
I am not sure that it is a fast development. Just compare to ours:
- first version of the product
10/23/2003 - AidAim Accuracer v.1.20
12/09/2003 - ComponentAce Absolute v.1.00
- first version with in-memory table support
07/15/2003 - AidAim SQLMemTable v.1.00
10/23/2003 - AidAim Accuracer v.1.20
12/24/2003 - ComponentAce Absolute v.2.00
- first version with multi-thread support
10/23/2003 - AidAim Accuracer v.1.20
12/24/2003 - ComponentAce Absolute v.2.00
- first multi-user version:
10/23/2003 - AidAim Accuracer v.1.20
01/27/2004 - ComponentAce Absolute v.3.00
- first release of ODBC Driver
07/16/2003 - AidAim EasyTable ODBC Driver v.1.00
12/15/2003 - AidAim Accuracer ODBC Driver v.1.00
ComponentAce Absolute - planned to publish in April, 2004 (we are not sure that it will be released
yet – see the comment below)
- first Kylix version
01/14/2004 - AidAim Accuracer v.1.40
not planned - ComponentAce Absolute
- first client-server version
03/12/2004 - AidAim Accuracer v.3.00a
not planned yet - ComponentAce Absolute
As you can see it looks like the try of ComponentAce to convince the customers of fast development
by the greater number of the Absolute version in comparison with Accuracer. ComponentAce made minor
improvements in major releases while AidAim releases such insignificant improvements in the
versions with minor numbers.
>Contrary to Accuracer, Absolute Database was specially optimized for the single-user mode
There is nothing contrary. Accuracer is well optimized to work in single-user mode as well as in
multi-user.
>> Accuracer has ODBC Driver. Even our old product, EasyTable, has
>> ODBC Driver. Trust me, I know these guys, Absolute will have ODBC
>> Driver never, they do not wield such technology.
>Development of the ODBC Driver for the Absolute Database will be completed soon.
>It is expected to be released within the closest 2 weeks.
The facts are:
- EasyTable ODBC Driver is the property of AidAim Software as well as any of its parts, for
example, accomplished documentation (including published on our site) and the technology itself the
Driver is based on.
- Nobody at CompanentAce took no part in ODBC Driver development at AidAim.
When ComponentAce’s Driver will be published (if it will be done), we will investigate it narrowly
as well as any published materials. If any copies of part of our code, our documentation, or any
tracks of reverse-engineering and so on, or even any cold scent of our technology will be found,
we’ll take all legal action to defend our property and our rights.
>Absolute Database doesn't use EasyTable's encryption technologies.
Yes, it uses the old AidAim encryption technologies released in EasyTable and some others released
in FlexCompress, for example, when it was AidAim’s product. Absolute does not allow encryption
using binary key and initialization vector while Accuracer has the widest set of strong encryption
capabilities:
12 strong encryption algorithms:
- Rijndael, 128 bit key
- Rijndael, 256 bit key
- Blowfish, 448 bit key
- Twofish, 128 bit key
- Twofish, 256 bit key
- Square
- Single DES 8 byte Blocksize, 8 byte Keysize 56 bits relevant
- Double DES 8 byte Blocksize, 16 byte Keysize 112 bits relevant
- Double DES 16 byte Blocksize, 16 byte Keysize 112 bits relevant
- Triple DES 8 byte Blocksize, 24 byte Keysize 168 bits relevant
- Triple DES 16 byte Blocksize, 24 byte Keysize 168 bits relevant
- Triple DES 24 byte Blocksize, 24 byte Keysize 168 bits relevant
with 4 different modes:
- CTS
- CBC
- CFB
- OFB
and 2 different encryption schemes:
- password
- encryption key
>I am not acquainted with the new guy at AidAim - Roy Lahoy
His name is Ray.
>and I don't know why he is trying to discredit our company.
No more than you do in your e-mails: everybody shows the better sides to promote the own products.
Could not be this problem if the customers do not ask us (and so often) to explain why your product
and the materials on your site are very similar to ours (note that nobody asked why Accuracer is a
similar to DBISAM or NexusDB, but all ask why Absolute is very similar to EasyTable and Accuracer).
So you should not blame us for the facts which show our benefits and for that we have great number
of these facts, just work on your products and materials carefully and do not use dirty tricks to
promote your products.
Good luck in development!
With best regards,
Ella Perelman
sales manager
AidAim Software mailto:sa...@aidaim.com
Ella Perelman
We have a lot of customers’ questions why the documentation of Absolute and ComponentAce web site look like copies of ours. We have no facts that
ComponentAce steals our products except the statements above.
Many people ask us why Absolute is so similar to Accuracer and EasyTable but we never claim that ComponentAce are pirates.
Nevertheless we would like to comment some their words which are not fair to us.
> Absolute Database is designed to be fast on 1000 records and on
> 10'000'000 records. It has scalable architecture, whereas EasyTable
> becomes very slow with large number of records.
EasyTable is the fastest database on the small tables (up to tens of thousands records) -- see the tests on 10,000 records at
http://www.aidaim.com/articles/dbtests1.php
> And contrary to the Accuracer, Absolute Database has a single-user edition specially
> optimized to achieve high performance there.
It does not mean that Absolute is faster then Accuracer. We spent a lot of time to optimize single-user performance. Accuracer is one of the fastest
single-file database on about of 1,000,000 records and more even in single-user mode.
> The database file of Absolute Database Multi-User Edition have the same format as in
> single-user edition, so you can easily switch to the multi-user if
> you will need to. Of course we will provide special upgrade price for
> upgrade from single-user edition to multi-user.
As well as Accuracer. Accuracer Database System is available now in the following versions:
VCL: versions for Delphi and C++ Builder
CLX: versions for Kylix
SU - single-user: allows one database connection only
MU - multi-user (file server database)
CS - client/server (prerelease public version for testing only, we plan to start sales in April)
There are different types of licenses with and without source code.
Accuracer Database System has Accuracer ODBC Driver available for additional price.
ComponentAce compares their product to EasyTable because Accuracer has the most of Absolute features and many others.
> Absolute Database auto-detects database corruption caused by power
> loss during writing to database file and can automatically repair the
> database, neither EasyTable nor Accuracer have such possibility.
It is the false claim. EasyTable has automatic database repair function. Moreover it is not an advanced feature significative of great stability. It does
not prevent data corruption, it is an additional testimonial that there is a probability of data corruption. That’s why Accuracer has no such ‘the feature’,
it is much more reliable system. To learn details, please contact our Support Team (mailto:sup...@aidaim.com)
Best regards,
Andrew Harrison
Hi!
> Only one man at ComponentAce worked at AidAim Software about 3 years -- you are, Andrew Harrison,
> vice-president of the ComponentAce LLC, and nobody longer.
Thank you for this correction.
I should add also that only one another man at AidAim designed, developed and supported all those compression, encryption and compression products
for about 3 years, and nobody longer.
So I don't see any difference in experience of our teams.
> I am not sure that it is a fast development. Just compare to ours:
Absolute Database project started about 1.5 months later than Accuracer,
and we had different priorities in the development than you.
The dates of features implementation don't proof anything,
as the Absolute DB project was started about 1.5 month later.
Besides, we had different priorities in the development process.
So this comparison has no sense.
I can show it even with the 1.5 month of development odds
given to the Accuracer.
I can easily revert the situation:
Optimized single-user database:
12/09/2003 - ComponentAce Absolute v.1.00
02/02/2004 - AidAim Accuracer v.2.00
Multi-user with transactions
01/27/2004 - ComponentAce Absolute v.3.00
02/02/2004 - AidAim Accuracer v.2.00
Batch Move functionality
03/05/2004 - ComponentAce Absolute v.4.00
today - AidAim Accuracer
Compact string indexes:
12/09/2003 - ComponentAce Absolute v.1.00
not done yet - AidAim Accuracer v.2.00
Correlated subqueries
03/05/2004 - ComponentAce Absolute v.4.00
not done yet - AidAim Accuracer
We develop Absolute Database fast and we made significant improvements, many of the Absolute DB
features are not implemented not only in Accuracer, but also in most other BDE alternaitves:
such as correlated subqueries, compact string indexes and full auto-detect / auto-repair
of corruption (which may be caused by the unexpected power loss during the writing changes to the database file)
> - first client-server version
> 03/12/2004 - AidAim Accuracer v.3.00a
> not planned yet - ComponentAce Absolute
It's false, as many other false claims of the AidAim about plans of ComponentAce,
as AidAim doesn't have information about ComponentAce plans.
> As you can see it looks like the try of ComponentAce to convince the customers of fast development
> by the greater number of the Absolute version in comparison with Accuracer. ComponentAce made minor
> improvements in major releases while AidAim releases such insignificant improvements in the
> versions with minor numbers.
Let me show the truth once again.
Absolute DB history brief:
v.1.00 Single-user, single-thread database engine.
I think 1.00 can be named so without any doubts :-)
v.2.00 In-memory tables and multi-thread support.
AidAim itself considered even one of these features to be significant enough in EasyTable
to inrease EasyTable's version number to 5.00.
So I don't think they considered this improvement to be a bug fix :-)
v.3.00 Multi-user with transactions.
Once again AidAim considered even one of these features, transactions only,
to be enough to increase their Accuracer version number to 2.00.
So I don't think they considered this improvement to be a bug fix too :-)
v.4.00 SQL: correlated and non-correlated subqueries, IN, EXISTS, BatchMove.
Once again AidAim considered even half of these features
to be enough to increase their EasyTable version number to 6.00.
And so I don't think they considered this improvement to be a bug fix too :-))
Please, tell me, where are the bug-fixes? :-)
> The facts are:
> - EasyTable ODBC Driver is the property of AidAim Software as well as any of its parts, for
> example, accomplished documentation (including published on our site) and the technology itself the
> Driver is based on.
> - Nobody at CompanentAce took no part in ODBC Driver development at AidAim.
> When ComponentAce's Driver will be published (if it will be done), we will investigate it narrowly
> as well as any published materials. If any copies of part of our code, our documentation, or any
> tracks of reverse-engineering and so on, or even any cold scent of our technology will be found,
> we'll take all legal action to defend our property and our rights.
Our development of ODBC driver will be finished soon.
Of course we are developing it without use of AidAim's or any other parties intellectual property.
>Absolute Database doesn't use EasyTable's encryption technologies.
> Yes, it uses the old AidAim encryption technologies released in EasyTable and some others released
> in FlexCompress, ...
EasyTable provides only Rijndael, 256 algorithm.
Absolute Database provides the following algorithms:
- Rijndael, 128 bit key
- Rijndael, 256 bit key
- Blowfish, 448 bit key
- Twofish, 128 bit key
- Twofish, 256 bit key
- Square
and applies them in another way than EasyTable, so
I will state once again Absolute Database uses its own encryption technologies
which are much better than EasyTable's ones.
What's about IV and binary key in Accuracer'as encryption, they
are useless for most of the database developers because they are not crypto-experts to
use these possibilities right. But if they will not generate IV and binary key right they may
got a very weak encryption instead of strong.
> Good luck in development!
Good luck to you and AidAim team too!
Regards,
Andrew Harrison
ComponentAce http://www.componentace.com
Steve Moss
If you guys must bicker in this way, please take it offline - doing
what you are doing is hardly going to enhance either of your bottom
lines.
It is a pity that "Peter" saw fit to start off this inevitable
tit-for-tat nonsense by breaking confidences and publishing private
e-mails in the first place. I hope it serves as a lesson for all, not
that I believe it will...
--
Regards,
Steve Moss,
CoCo Systems Ltd.
Delphi 6.02, Win2K + SP4
Kevin Powick
says...
> This is really rather unseemly, and quite lacking in professionalism.
After reading through this "pissing contest", I'm not sure I would like
to deal with EITHER company.
--
Kevin Powick
Joe
"peter"_nospam.pls
Hello guys and girls!
Thank you all for the comments you made. The situation is cleared up for me.
ComponentAce is a good company, I apologize to them for my concerns.
I am sorry that I have to bring to light the private mails, but the mails from the companies were in apparent contradiction.
AidAim and ComponentAce didn't break the rights of each other.
Database products of both ComponentAce and AidAim have its own advantages and disadvantages.
So I think that each customer will decide which product is the best for his/her purposes.
I prefer AbsoluteDB and I think I will buy it soon.
Thanks to all,
Peter
Eric Schreiber
> After reading through this "pissing contest", I'm not sure I would
> like to deal with EITHER company.
That's pretty much the same conclusion I arrived at. It's disturbing to
see this lack professionalism.
Matthew Jones
when something like this comes up. Fortunately both companies have been
quite restrained here, though there are some phrases that sound bad if you
don't interpret them right which I assume is a simple "non-native
language" issue. There is obviously bitterness still in the air over the
split. Move on and get over it I say.
/Matthew Jones/
Bert Binnenmarsch
They don't waste their time fighting other companies.
Bert
Didier Largange
I don't think it is a good reason for a choice... pricing and
single-file is a strong difference between their products and NexusDB.
> They don't waste their time fighting other companies.
Just remember a few years ago between IW and EWF... ;-)
The current problem is mainly due to the late arrival of Component Ace,
and their common DB target. But I'm sure time will make their products
and strategy more and more distinct.
Didier
Didier Largange
>
> /Matthew Jones/
I agree with you.
Multi-file databases are definitely not for me so either one of them is
definitely my choice.
ie : I have a 10 000 users utility that use Aidaim EasyTable for over 3
years now, and I'm very satisfied.
Didier
Ella Perelman
> That's pretty much the same conclusion I arrived at. It's disturbing to
> see this lack professionalism.
Hello Eric,
What do you see the lack of professionalism in?
When the customer posted private correspondence from both AidAim Software
and ComponentAce companies, we immediately contacted ComponentAce and
offered to close discussion because we are ready to write that they are not
pirates. Also we offered to ComponentAce to adhere to our agreement about
no competition to not publish on our sites as well as on any other organs
of public opinion anything about other party or its products and to solve
such problems together.
However, the guys at ComponentAce preferred to go by other way...
They published on their site and on this newsgroup materials without any
preliminary discussion with us and they refused any dialogue.
We have to answer. We will not publish anything on our site but in
newsgroup we cannot leave without any answer queries like: we are waiting
for official comments from AidAim.
We only reacted against unfair soiling our products. We will not answer to
tries to blacken our reputation anymore.
If you need comments please contact us directly at
sa...@aidaim.com
Best regards,
Ella Perelman
AidAim Software mailto:sa...@aidaim.com
Joe
hundreds of data files.
>
> Out of personal and business interest:
>
> Why do you prefer a single file solution?
>
Joe
Hannes Danzl[NDD]
>
> I don't think it is a good reason for a choice... pricing and
> single-file is a strong difference between their products and NexusDB.
Out of personal and business interest:
Why do you prefer a single file solution?
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm
Hannes Danzl[NDD]
> Multi-file databases are definitely not for me so either one of them is
just one thought on this: if you still have clients on Win9x and clients with
lots of data you've no other choice than go for multi-file databases. not an
issue on higher systems though.
i guess it comes down to preference otherwise ...
damian marquez
news:406b...@newsgroups.borland.com...
> You got that right. Go with DBISAM or NexusDB before either of them.
Well indeed with such powerful options like the ones you mention above (not
to
mention the free, ever-growing Firebird), they would really have to be more
careful,
since vendor reliability becomes an important value when the technical
competence is so
tight...
Eric Schreiber
> I think many people prefer it just because it is neater. No need to
> ship hundreds of data files.
I cases where you're shipping *data* in the files, I suppose that makes
some sense, but with installation building program, you generally only
ship the single-file installer anyway.
If one is shipping blank data files, well, that strikes me as bad
design. In my opinion, a database application should be able to create
its own files automatically if they're missing.
Joe
data in it, and I dont really want to create in on the fly.
Hannes Danzl[NDD]
> hundreds of data files.
hm. normally a multifile database keeps files of a database in *one* directory.
so i guess the work for adding it to the installer is excatly the same.
Kevin Powick
han...@nexusdb.dbnexus.com says...
> > I don't think it is a good reason for a choice... pricing and
> > single-file is a strong difference between their products and NexusDB.
>
> Out of personal and business interest:
>
> Why do you prefer a single file solution?
Personally, I prefer multi-file database solutions for several reasons:
* I always viewed single file solutions as having "all my eggs in one
basket". If the single file is corrupted, you potentially lose ALL
your data.
* Having multiple files can aid in customer support, allowing a
potentially small, individual file from a large multi-file system to be
e-mailed, to support for analysis and correction if necessary.
* There may be more flexibility with regard to location of individual,
files and the ability to share them among applications I.e. country-
codes, state-codes, etc.
* There may be more flexibility in system backup decisions. I.e.
omitting certain, large log files from the server backup.
--
Kevin Powick
Joe
bit less housework and less room for error. Personally I have no preference
either way.
Bert Binnenmarsch
news:MPG.1ad6832d7...@newsgroups.borland.com:
> Personally, I prefer multi-file database solutions for several reasons:
I couldn't have said it better.
These are really very good reasons, especially the second one.
Bert
John McTaggart
> hundreds of data files.
Easier to back-up as well..
John McTaggart
Michael Baytalsky
You can zip files into self-extractor... Are you saying you're mailing 20-30 MB file not
zipped?
Regards,
Michael
"Joe" <J...@none.com> wrote in message news:406c...@newsgroups.borland.com...
Hannes Danzl[NDD]
hm. I'm happy to hear that the answers so far vote for multi file :)
Still, can someone point out some good reasons for single file?
Eric Schreiber
> > Why do you prefer a single file solution?
>
> hm. I'm happy to hear that the answers so far vote for multi file :)
>
> Still, can someone point out some good reasons for single file?
I can actually appreciate Joe's "neatness" answer. One of the things
that first made me investigate FlashFiler (and now NexusDB) is that for
single-user software, I could compile all the engine files directly
into my application. With the DB engine I was using prior to that, I
had to include two DLLs every time. And that's two more files that an
end user might muck with, breaking the system, and pointing the finger
for the problem at me, the developer.
That sort of thing isn't really a consideration for me any more, and I
know that the more complex a piece of software is, the more likely it
is spread across multiple files. And while it's why I first looked at
FF/NDB, it's certainly not why I stuck with them. NexusDB chews gum,
takes names, *and* kicks ass - that's why I use it.
Still, I can understand Joe's feelings about neatness.
Eric Schreiber
> > I think many people prefer it just because it is neater. No need to
> > ship hundreds of data files.
>
> Easier to back-up as well..
(devil's advocate mode on)
Debatable. Formal backup programs generally have well-designed
interfaces, so that the difference between selecting one file and
thirty files is nothing more than about three mouse clicks.
For 'poor-mans' backup (like my frequent backups to disc), it makes no
difference. I generally grab an entire directory structure, so I can
completely ignore the individual file count.
To pick a very specific case, I can see an all-in-one database file
format as actually making backups harder. If the data size is very
large, when it exists in a single file that file may not fit onto the
backup medium (poor-man's approach, again), whereas if it's in multiple
files, odds are better that no individual file will be too big to fit.
Hannes Danzl[NDD]
> format as actually making backups harder. If the data size is very
> large, when it exists in a single file that file may not fit onto the
> backup medium (poor-man's approach, again), whereas if it's in multiple
> files, odds are better that no individual file will be too big to fit.
hm. for a c/s database both methods won't work. At least not in a 24/7
environment. The backup needs to be done by the db engine or a db client,
otherwise you the consistency is gone. most db engines lock the files
exclusively anyways for this reason....
Mike Williams (TeamB)
> With the DB engine I was using prior to that, I
> had to include two DLLs every time
I believe that by "single file" we're talking about the database, not the
engine. For instance, DBIsam compiles into the exe but the each table has
at least a DAT file and an IDX file. InterBase, on the other hand, puts
the entire database in a single *.GDB file.
--
-Mike (TeamB)
Kevin Powick
han...@nexusdb.dbnexus.com says...
> hm. for a c/s database both methods won't work. At least not in a 24/7
> environment. The backup needs to be done by the db engine or a db client,
> otherwise you the consistency is gone. most db engines lock the files
> exclusively anyways for this reason....
It is impossible to get a single, "consistent", snapshot of your entire
database that represents a moment in time using any "backup" method if
there is activity on the database during the backup.
If the db engine or client "locks" files, or the entire database for
that matter, you really don't have a 24/7 operation because these files
or entire db will not be accessible during this backup period.
For 24/7 operations, the only way to do this is mirroring and/or
transaction journaling.
Backups try to _minimize_, not eliminate, data loss. For many
companies that run 24/7, but only do backups once every 24 hours, the
reality is that any changes done to the data between when the backup on
day 1 starts and the backup on day 2 starts run the risk of being lost.
--
Kevin Powick
Didier Largange
>
> just one thought on this: if you still have clients on Win9x and clients with
> lots of data you've no other choice than go for multi-file databases. not an
> issue on higher systems though.
For big databases I use FireBird, as it becomes more and more easy to
market. :)
>
> i guess it comes down to preference otherwise ...
Sure.
Another point is that in some cases, I don't want to show implementation
details like tables. Even if they are encrypted. (May be I'm a little
paranoid <G>)
Anyway, you make a really great job with NexusDB !
Didier
Didier Largange
>
> Why do you prefer a single file solution?
I started developpement with Paradox, and it was not very cool...
I do prefer single file solution as people do prefer Access file format.
So simple to use, backup, share, deploy. No need of any custom tool to
do that.
Also, I've had so many problem with synchronizing or missing files in
Paradox that I don't feel very confortable with multi-file.
This also the main reason why I work with FB instead of MySQL.
Didier
Hannes Danzl[NDD]
> database that represents a moment in time using any "backup" method if
> there is activity on the database during the backup.
> If the db engine or client "locks" files, or the entire database for
> that matter, you really don't have a 24/7 operation because these files
> or entire db will not be accessible during this backup period.
not true. with NexusDB's integrated backup you get a consistent state of the
database in the backup AND normal usage can go on. It's done with our unique
snapshot transaction system.
> For 24/7 operations, the only way to do this is mirroring and/or
> transaction journaling.
see above.
> Backups try to _minimize_, not eliminate, data loss. For many
> companies that run 24/7, but only do backups once every 24 hours, the
> reality is that any changes done to the data between when the backup on
> day 1 starts and the backup on day 2 starts run the risk of being lost.
naturally true. even when mirroring or with hotbackups you can't be sure, just
think of malign statements run accidentally.
Hannes Danzl[NDD]
> So simple to use, backup, share, deploy. No need of any custom tool to
> do that.
> Also, I've had so many problem with synchronizing or missing files in
> Paradox that I don't feel very confortable with multi-file.
> This also the main reason why I work with FB instead of MySQL.
so if you would have a dbengine that *is* using multifile BUT allows to
create/deploy/backup single files (in whatever way) mostly automatic (for sure
automativ at the endusers side) you would consider it for your development?
Hannes Danzl[NDD]
Thanks! We try to fit the developer need so we try to look at all this stuff
<g>
TJC Support
program data that is read-only, and the customer won't be making any changes
to. Currently, we're still using Turbopower's old BTree Filer, which has
proven to be adequate for our needs even in its state of ancient-ness (or is
that ancient-hood? :^)). For these files only, I'd like to have not only a
single file database, but the next step, which is for that database to be
tucked away in the executable. EasyTable can do this, and it's being
evaluated for that purpose. We also have some data files that are created
when the app is run for the first time, and contain user created data. They
are generally very small, likely to never have more than a couple hundred
records. However, a few users are using these in a multi-user, networked
environment, which EasyTable can't do, and I haven't seen any mention of the
capability of storing the DB in the executable for Accuracer. So, we
haven't made any decisions yet. BTF still works, though it doesn't do
everything we'd like to do.
Van Swofford
Tybee Jet Corp.
"Hannes Danzl[NDD]" <han...@nexusdb.dbnexus.com> wrote in message
news:406dcc14$1...@newsgroups.borland.com...
Eric Schreiber
> I believe that by "single file" we're talking about the database, not
> the engine. For instance, DBIsam compiles into the exe but the each
> table has at least a DAT file and an IDX file. InterBase, on the
> other hand, puts the entire database in a single *.GDB file.
Yes, the original discussion was about the data files. I embraced and
extended to include the other files that are needed by an application.
Eric Schreiber
> hm. for a c/s database both methods won't work. At least not in a 24/7
> environment.
No argument there. I was thinking strictly about small, single user
kinds of applications (which is what most of my software has been,
though one particular program has long since quit being 'small').
> The backup needs to be done by the db engine or a db
> client, otherwise you the consistency is gone.
Speaking of which, I really need to take a look at the backup feature
of NexusDB. I had developed a backup routine under FF that closed all
the tables, copied them to a user-selectable backup location, then
re-opened the tables. When I converted to Nexus, I kept this approach
for simplicity's sake, even though I'm certain the NexusDB backup
function is a much better way. Time constraints have kept that change
on a back burner.
Kevin Powick
han...@nexusdb.dbnexus.com says...
> > It is impossible to get a single, "consistent", snapshot of your entire
> > database that represents a moment in time using any "backup" method if
> > there is activity on the database during the backup.
> > If the db engine or client "locks" files, or the entire database for
> > that matter, you really don't have a 24/7 operation because these files
> > or entire db will not be accessible during this backup period.
> not true. with NexusDB's integrated backup you get a consistent state of the
> database in the backup AND normal usage can go on. It's done with our unique
> snapshot transaction system.
There are many systems that allow normal usage while a backup is in
progress. I was just saying that if the lock file or lock database
method is used, as described by the previous poster, then those
files/db are not accessible while they are locked.
Regarding your backup system. Are you saying that in a very active
system, while the backup is going on, all data that changes during the
time the backup is being made is also backed-up?
If so, it seems that, in theory, you could end up with a backup cycle
that never ends as it must keep backup up changes that happen while the
backup is running. More likely, I suspect that the transaction or
journaling files are the last thing backed-up in the cycle and the
trans/journal process is momentarily paused so that it can be done
before write backs are committed.
Of course, not being a db engine designer, I'm only guessing ;-)
--
Kevin Powick
Hannes Danzl[NDD]
> single file database, but the next step, which is for that database to be
> tucked away in the executable.
ic. never thought about that before ...
> evaluated for that purpose. We also have some data files that are created
> when the app is run for the first time, and contain user created data. They
> are generally very small, likely to never have more than a couple hundred
> records. However, a few users are using these in a multi-user, networked
> environment,
hm, i don't think that any product supports that.
Hannes Danzl[NDD]
> system, while the backup is going on, all data that changes during the
> time the backup is being made is also backed-up?
no. it backs up the state of the database when you started backing it up. The
snapshot transaction mechanism allows that. Short said: it's versioning
transaction data in it's own block manager. for more details i think you can
find it in our free manual or otherwise come to the newsgroup or chat. Thorsten
surely is happy to discuss details :-)
Tim Young
<< Yeah, I know. But i often will ship a demo database that may have 20-30mb
of data in it, and I dont really want to create in on the fly. >>
Most of the engines provide native backup into a single file (DBISAM
included), so that's always an option for shipping a one-file, compressed
version of any database.
--
Tim Young
Elevate Software
www.elevatesoft.com
Alessandro Federici [RemObjects Software]
> Out of personal and business interest:
Hannes, why would anybody want a multi file solution is the real question.
As you know very well, I *love* NexusDB, but multifile is something I'd love
for you guys to remove at a certain point in the future. Is more complex to
manage than using a single file and is definitely too 80's <G>
Alessandro Federici [RemObjects Software]
[..]
> hm. normally a multifile database keeps files of a database in *one*
directory.
> so i guess the work for adding it to the installer is excatly the same.
It's not. It's something that requires X checks,. rather than 1, especially
when you update the product.
Alessandro Federici [RemObjects Software]
news:MPG.1ad6832d7...@newsgroups.borland.com...
[..]
> * Having multiple files can aid in customer support, allowing a
> potentially small, individual file from a large multi-file system to be
> e-mailed, to support for analysis and correction if necessary.
That would only work if your DB doesn't have referential integrity, which is
not the case in regular production products.
> * There may be more flexibility with regard to location of individual,
> files and the ability to share them among applications I.e. country-
> codes, state-codes, etc.
You can do that with single file solutions as well, as long as the db is not
dumb that doesn't let you query one db from another.
> * There may be more flexibility in system backup decisions. I.e.
> omitting certain, large log files from the server backup.
Doable and done with solutions like the backup of MSSQL very easily.
Jean-Francois Nifenecker
> Is more complex to manage than using a single file and is
> definitely too 80's <G>
One can't be too 2080's <g>
--
Jean-Francois Nifenecker, Bordeaux (EU)
Eric Schreiber
> "Hannes Danzl[NDD]" <han...@nexusdb.dbnexus.com> wrote in message
> news:406c...@newsgroups.borland.com...
> > Out of personal and business interest:
> > Why do you prefer a single file solution?
>
> Hannes, why would anybody want a multi file solution is the real
> question. As you know very well, I love NexusDB, but multifile is
> something I'd love for you guys to remove at a certain point in the
> future. Is more complex to manage than using a single file and is
> definitely too 80's <G>
I disagree strongly. I certainly wouldn't object to NexusDB making
single-file databases an option, but I would not like it to become the
only available format.
I don't see any complexity - it's not as though multiple tables are
scattered all over the drive. If the program is well designed, all the
data is in a single location; one which can be treated as a single
object, for that matter. What is a single file db? It's a container of
tables. What is a directory on a hard drive? It's a container of files.
But you know what? When I need to delete a single file (often the case
as I design tables for custom reports), I don't have to run a database
application, wait for it to start, navigate to the db/table in
question, then delete it. When the tables stand separately, I can nuke
the table in just two clicks.
When my clients want some change to their software that affects a
single table, right now I can dial in (old-fashioned modem, woot), pick
up that single file, make and test the necessary changes, and return
the file to them fairly quickly. If all the data was in a single file,
it would be several megabytes in size, which takes a lot longer to
transfer.
I know you're being humorous when you make the 80s reference, but
sometimes things remain unchanged because they're a good way to solve a
problem. The wheel, for example - very stone age, but the perfect shape
for the job.
Ella Perelman
> environment, which EasyTable can't do, and I haven't seen any mention of the
> capability of storing the DB in the executable for Accuracer. So, we
> haven't made any decisions yet. BTF still works, though it doesn't do
> everything we'd like to do.
>
> Van Swofford
> Tybee Jet Corp.
Dear Van Swofford,
We plan to release this feature in Accuracer in one of the closest version
(after v.3.01 Client-server will be released).
But you will be able to use it in single-user mode only because of locking .exe
file by OS.
Best regards,
Ella Perelman
AidAim Software mailto:sa...@aidaim.com
Jean-Francois Nifenecker
>
> I disagree strongly. I certainly wouldn't object to NexusDB making
> single-file databases an option, but I would not like it to become the
> only available format.
> [...]
> I know you're being humorous when you make the 80s reference, but
> sometimes things remain unchanged because they're a good way to solve
> a problem. The wheel, for example - very stone age, but the perfect
> shape for the job.
Fully agreed and endorsed.
TJC Support
Van
"Ella Perelman" <in...@aidaim.com> wrote in message
news:406FD501...@aidaim.com...
Kevin Powick
alef@rem_________objects.com says...
This small "inconvenience" does not outweigh the advantages, IMO of
course. :-)
--
Kevin Powick
Kevin Powick
Schreiber" <eric at kobayashi dot com> says...
> > Hannes, why would anybody want a multi file solution is the real
> > question. As you know very well, I love NexusDB, but multifile is
> > something I'd love for you guys to remove at a certain point in the
> > future. Is more complex to manage than using a single file and is
> > definitely too 80's <G>
>
> I disagree strongly. I certainly wouldn't object to NexusDB making
> single-file databases an option, but I would not like it to become the
> only available format.
I strongly agree with your disagreement. ;-)
--
Kevin Powick
Kevin Powick
alef@rem_________objects.com says...
> > * Having multiple files can aid in customer support, allowing a
> > potentially small, individual file from a large multi-file system to be
> > e-mailed, to support for analysis and correction if necessary.
> That would only work if your DB doesn't have referential integrity, which is
> not the case in regular production products.
It's not just for Ref integ issues. A lot of DBs don't have built-in
ref-integ anyway, or it's not set-up correctly as part of the design.
> > * There may be more flexibility with regard to location of individual,
> > files and the ability to share them among applications I.e. country-
> > codes, state-codes, etc.
> You can do that with single file solutions as well, as long as the db is not
> dumb that doesn't let you query one db from another.
I think you're focusing on Nexus, when the I "believe" the question was
more general. If you can do it all from Nexus, then great.
> > * There may be more flexibility in system backup decisions. I.e.
> > omitting certain, large log files from the server backup.
> Doable and done with solutions like the backup of MSSQL very easily.
Great if you're using MSSQL.
--
Kevin Powick
Hannes Danzl[NDD]
because it's convenient and proven?
> As you know very well, I *love* NexusDB, but multifile is something I'd love
> for you guys to remove at a certain point in the future. Is more complex to
> manage than using a single file and is definitely too 80's <G>
The reason why i asked the question in the first place was tioo figure out why
people want single file and how the reactions will be. It looks like there's
demand, it's on our wishlist since ages and we hear you all. it will surely be
discussed in the next meeting and we look how it fits into our framework.
One thing is clear though, it will be optional.
Fwiw: storing a full readonly db as resource can be quite easily done already
with the current version :)
Hannes Danzl[NDD]
i don't follow you. most installers have a "add directory" option that works
just the same as the "add file" one ...
Kevin Powick
han...@nexusdb.dbnexus.com says...
> The reason why i asked the question in the first place was tioo figure out why
> people want single file and how the reactions will be. It looks like there's
> demand, it's on our wishlist since ages and we hear you all. it will surely be
> discussed in the next meeting and we look how it fits into our framework.
> One thing is clear though, it will be optional.
Glad it will be optional. I wouldn't even consider the product if it
became strictly a single file db.
--
Kevin Powick
Robert
> One thing is clear though, it will be optional.
>
And a total waste of developer resources, IMO, and a way to introduce bugs
into the program. I really can't understand why anybody cares. Let the DB
developer do what they think is best.
Robert
Hannes Danzl[NDD]
that's what we try to figure out: will the additional option create enough new
sales to justify the development.
> and a way to introduce bugs into the program.
no worries there. NexusDB is completely abstracted. The actual file access is
done in one class, implementing an abstract storage class. There's no hard
references into any of these implementations, the actual instance is created on
a per database basis from a specific descriptor and there's support for
different implementations to be registered into the framework at the same time
as well. Implementing the single-file db system would not touch any other unit
but just add an additional implementation descriptor to the class system.
> I really can't understand why anybody cares. Let the DB
> developer do what they think is best.
well, shouldn't we tools developers listen to what people want? Here is
obviously a thing that not only one person but several want to have. We surely
care about what the market wants, but of course projected sales have to somehow
match the costs. We've got quite some comments to think about, so lets see.
Thanks every one for their opinions.
Didier Largange
>>I do prefer single file solution as people do prefer Access file format.
>>So simple to use, backup, share, deploy. No need of any custom tool to
>>do that.
>>Also, I've had so many problem with synchronizing or missing files in
>>Paradox that I don't feel very confortable with multi-file.
>>This also the main reason why I work with FB instead of MySQL.
>
>
> so if you would have a dbengine that *is* using multifile BUT allows to
> create/deploy/backup single files (in whatever way) mostly automatic (for sure
> automativ at the endusers side) you would consider it for your development?
>
I evaluated DBISAM some years ago and was very impressed, and it seem
that you are following the same way.
Matter of taste, I'm sure that you can acheive the same ease of use, but
I rather have to deal with single file. As for my single file
executables in Delphi. ;-)
Didier
Hannes Danzl[NDD]
> executables in Delphi. ;-)
ok, noted :)
Kevin Powick
alef@rem_________objects.com says...
This coming from a guy that sells a multi-file plug-in framework
(Hydra). It seems to me that must take a few checks to make sure
you're shipping everything required for an application update. <vbg>
--
Kevin Powick
Kevin Powick
@hotmail.com says...> news:MPG.1add164b8...@newsgroups.borland.com...
> > > for you guys to remove at a certain point in the future. Is more complex
> to
> > > manage than using a single file and is definitely too 80's <G>
> For sure. Everyting should come bundled in one gigantic file under Windows.
> <g>
>
> Robert
You've attributed the quote to the wrong poster.
--
Kevin Powick
Robert
to
> > manage than using a single file and is definitely too 80's <G>
>
For sure. Everyting should come bundled in one gigantic file under Windows.
<g>
Robert