At my work, my co-workers are considering using hyperfile as a database server for a windev project. I don't even know that kind of database, it's from PCSOFT, the company that develops windev.
Since windev can also work with microsoft sql server, I'm looking for advice on that kind of database (performance, stability, etc) from people who already used it.
Regards!
It depends on the size of your project. Actually, Windev works well with HyperFileSQL. It has been designed for it ! By using another DBMS, you cut yourself some feature such as direct-reading/modifying/deleting in your tables.
Your performances will decrease significantly as soon as you have a nice amount of records in a table (> 100'000). Your database management will become a nightmare since you can't execute several SQL requests at the same time. In example, i'm using another tool developped by a french guy to manage my databases and execute some updates.
Despite of this, it's stable and provides an easy way to interact with Windev's fields.
In my opinion, Hyperfile SQL should be used with small applications with a small amount of features and datas.
Adding upon what Samuël Tremblay already wrote, I would say that after 2+ years of using Windev with HFSQL (old name is HyperFile SQL), here are my conclusions (I have used Windev versions 20 and 22):
PROS:
replication of a database to another server is rather easy to setup. You can choose to replicate a whole database or a selection of tables. But DBMS like PostgreSQL are actually offering advanced replication setups (https://www.2ndquadrant.com/en/resources/pglogical/).
easy export to a Microsoft Excel file of a query/table
create and change the schema/structure of your database through a graphical user interface (GUI)
CONS:
When you use the database server provided by Windev (i.e. HFSQL), you must use Windev (that is imposed upon you). You cannot interact with your database with another language/framework other than Windev, you are forced to use Windev to query a HFSQL database. If you use instead a DBMS like PostgreSQL, mySQL/MariaDB, etc. you can (and will be able) to query the database with some other language : C++, Java, JavaScript, etc.
Say that you wanted now to open your data to customers through a web app, you will actually need to use their other software Webdev from their software suite (and buy it actually).
Or say, some day, you want to develop a simple app for smartphone with Qt or else. Well, if your database runs on HFSQL, then you will not be able to query your database unless you use Windev (actually Windev Mobile that you also need to purchase).
UNIQUE constraints are not working with the presence of NULL (two rows containing NULL would be considered to violate the UNIQUE constraint).
(almost) every time you update your "analyse/analysis" (basically the database schema), you will also need to update your binary executable. You will need to recompile your software and distribute it again to the users. For example, say you modify a table by adding a column, or modifying the type of a column, then you need to recompile. The executable that the users have will not run, it will say that the version of the "analysis" (schema) on the database is not the same as the one in the executable, and will stop. BAM !
the HyperFile SQL (HFSQL) server is not so stable, it will crash (often) when executing slightly advanced queries with not so many rows...
You cannot create scripts to query the HFSQL database : you must create a binary executable (a new project) with Windev. Say you want to quickly modify something --> you need to recompile (and have a Windev IDE with you).
Say you are on the go, on some trip, and you forgot to bring your computer with the Windev Dongle key (a license cryptographic USB key : it you don't have it, you cannot run Windev), and you need to do some work on the database. PCSoft provides a software called HFSQL Control Center (a GUI software) that can interact with the database, but unfortunately it cannot be downloaded from the internet. You actually obtain it when you buy Windev, and you are allowed to distribute it to whom you want, but it cannot be downloaded from PCSOFT website.
Whereas if your database engine is another one, say PostgreSQL or MariaDB, you can simply download PGAdmin or the equivalent, and boom you can interact with your data.
It seems to me that HFSQL is not a real/genuine DBMS, let me explain myself : the constraints you can set in the analysis (UNIQUE for example), are not always respected. For example, after adding a UNIQUE constraint in the schema (analysis) and compiling the program, I have seen that if I would insert some data in a table from the executable, it would detect the violation of the UNIQUE constraint when it should happen. However if I would insert the same set of data through the HFSQL Control Center, the constraint would not be enforced and the duplicates would be insterted.
There would be more to say ...
Bottom line: From my own experience, I would strongly encourage anybody, who wants to develop a reliable and dependable software that "must" be developed with Windev (and that needs data persistence), not to use their database HFSQL. You would be much better off using a RDBMS such as PostgreSQL or MariaDB. We are actually going to port our databases from HFSQL to PostgreSQL this Summer.
You should carefully consider what sql functions you will use. For example deg2rad, rad2deg, ... not working correctly.
Also if you want to use it on a mobile device (Windev Mobile for iOS or Android) you should use SQLLite. Because HyperFile uses a lot of memory and it will be a problem on mobile.
If you want a free database, use PostgreSQL, the Windev connector for PostgreSQL is free to download and install on your windev as a replacement for HFSQL, it will be way more powerful while using the usual hFunctions like you would with HFSQL, plus you will find a ton of docs on the web to do powerful stuff.
HFSQL is in fact the same as an old ISAM DBASE database so it requires re-indexations and things like that of those older DB systems era.
PostgreSQL is like having a free Oracle DB with all the powerful features and reliability, we dropped HFSQL for this and performance has increased tenfold plus all the other benefits while keeping our code pretty much the same, every day feels like we discover freebies and gifts from ProsgreSQL since our migration :)
Free VS Free... You gotta go with power and sheer size of web documentation and poeple available to help .
In WinDev Mobile 18 and up, you can use Hyperfile on the device. And it is recommended from me, because it is faster and SQLLite restrict blob-size to 1MB!!
#Spek memory usage of HyperFile on the phone? Can you give me any values? I think if you want to make a full feature APP you cannot ignore the benefits of HyperFile...
FYI: New in Windev version 19: Hyperfile SQL is ACID.
Related
The database for one the application that I am working on is not confirmed yet by the business.
Best guess is Oracle and DB2.
What I've heard is initially the project will go live with DB2 V9 and then to Oracle 11g.
We are using Spring 3.0.5, Hibernate 3.5, JPA2 and JBoss 5 for this project
So what are the best practices here going into the build phase and test phase?
Shall I build using DB2 first and worry about Oracle later (this
doesn't sound right)?
Or, shall I write using JPA (Hibernate) and
then generate the database schema?
Or something else?
PS: I've no control over the choice of the DB, what and when, as these are strategic decision made by people sitting in nice rooms getting fat cheques and big bonuses.
Thanks,
Adi
Obviously you are loosing the access to specific features of the database if you are writing your application database agnostic. The database is, except for automatic optimizations done by JPA and Hibernate, reduced to common features. You have to set some things to automatic and trust JPA/Hibernate to do it right that you could set specifically if you knew the database (e.g. id generator strategies).
But it seems that the specific developer features of the database are not relevant for the decision so they can't be relevant to the application. What other reasons may influence the decision (like price, money, cash, personal relations, management tools, hardware requirements, existing knowledge and personell) can only be speculated about.
So IMHO you don't have a choice. Strictly avoid anything database specific. That includes letting the JPA/Hibernate generate the schema (your point #2). In this project setup you shouldn't tinker with the database manually.
Well... sadly there ARE some hidden traps in JPA/Hibernate developement that make it database dependent (e.g. logarithmic functions are not mapped consistenly). So you should run all your tests against all possible databases from day one. As you write "Best guess is..." you should just grab any database available and test against it. Should be easly setup with the given stack.
And you should try to accelerate the decision about the database used, if possible.
Just "write using JPA (Hibernate)" develop it to be de database agnostic. Put all you business logic in java code not stored procedures.
If you are using spring you don't need jboss you could use just tomcat, about a quarter of the foot print, and much simpler imho.
Spring vs Jboss and jboss represents all that is bad, while spring represents all that is good in Java enterprise development
We have add this issue and had to migrate late in the project, leading to a lot of extra works, frustrations and delays.
My advise is to define an abstract layer. Go to the point you may have a data model without any database, say with tables or text files.
Then when you have to switch to some database, you can optimize for it, while staying free to continue application development on any already developped model. So you don't delay the developpers on the app while one is tuning the DB2 layer. When everything is duly validated, the team can switch on it.
I will disagree with the currently accepted answer suggesting avoiding database specific things. From a performance perspective, that would be a pity, and it's definitely doable.
JPA/Hibernate and also jOOQ can abstract over a lot of things and if you're using the query builder APIs of either technology (criteria query in JPA, or jOOQ for more advanced SQL), you can get very far in a vendor agnostic way without removing all the vendor specific stuff. For example, you can easily create a vendor specific predicate like this:
.where(oracle ? oracleCondition() : db2Condition())
What you should do from the very beginning of such a project, once you know you'll have to support both dialects is to run integration tests on both database products. For this, I recommend testcontainers, which makes running such tests quite simple. If you have to add support for another dialect, and if you're using one of the above abstractions, you can simply add another testcontainers configuration, check if your application still works, tweak 2-3 things, and you're set.
Disclaimer: I work for the company behind jOOQ.
Our company is upgrading all work computers soon and no longer supporting MS Access. Unfortunately, a lot of important database is stored in a plethora of Access databases with many differing styles of interfaces. Storing it all on a database server is out of the question. What is a good portable (non-server) database system that I can use?
The one I'm leaning toward is SQLite, but I'd also like to be able to write interfaces to query the data. If I use SQLite, what is a good way to write a query interface that will work on a lot of Windows machines natively?
EDIT: Data migration will not be a problem. I'm more worried about interface migration. What is a good way to write a query interface for one of these portable database systems?
EDIT2: It seems that there's some confusion as to what I mean by "query interface". I don't need a complete query system. I'm simply looking to create a simple frontend through which I can search the Database by table and by fields.
Judging by the title of your question, you are concerned about what database (i.e. data container) should be used in place of Microsoft Access. However, viewing your question and the ensuing answers and comments, your greater concern is actually what to use to design the Application/user interface, what you are referring to as the "query interface".
Here's a couple things you need to realize:
1) SELECT queries allow you to extract data from a database. However, the data has to get into the database somehow. At no point have you specified whether or not your so-called "query interface" is also used for data entry. If it is in fact used for data entry, as I suspect it is, then you should concern yourself with how your going to design your "application", not your "query interface". Data entry often requires a certain amount of guidance and logic that is defined outside of the database. This logic includes (but is not limited to) things like validation rules, input masks, parent child relationships that are enforced by the GUI design. This is essentially an application, not merely a "query interface". Applications are usually designed to make data entry easier than having the user enter data directly into the tables. But even here you must realize that ultimately a user can't even enter data directly into a table without some type of application GUI, whether that GUI is something you've designed or not.
2) Microsoft Access is a Rapid Application Development (RAD) tool that allows you to quickly and easily design and save queries, forms, and reports. It appears to me that you're real question is, What RAD tool other than Microsoft Access can I use to develop queries and forms for viewing and entering data in small desktop databases? And what database would you recommend we use together with the RAD tool you're recommending?
Assuming I've properly defined your actual question, allow me to give my own viewpoint on this question. First, as has already been pointed out in another answer, as long as the clients are running MS Windows, you don't really need to move away from using Access/Jet/ACC as your database (data container, the part that holds the tables). As long as MDAC is installed an Access database should be "machine readable".
It seems to me the more important question here is what RAD tool should you use in place of Microsoft Access? After you answer this question perhaps it will help you answer the first question, of what database should be used. In answer to this question, let's be honest. While Microsoft Access has it's shortcomings, you probably won't find any other RAD tool that allows you to so easily create Forms for data entry. FileMaker Pro is one of the only competing products that I know of.
Yes, you could use Visual Studio .Net to create .exe runtimes. These runtimes can include forms for viewing and entering data as well as reports. I think you'll find that the learning curve is pretty major, especially if you are not yet familiar with ADO.Net which is very different from DAO or ADO Classic. If you want to give your users ways to create their own queries/filters or reports you'll have to design this functionality into your GUI since Visual Studio doesn't give you the easy wizards and design tools you'll find in Microsoft Access. While Visual Studio is far more powerful than MS Access, you need to realize that the development time for even the simplest of applications is probably going to be much higher, especially when you are first learning.
Are there any other RAD tools you could possibly use? I know little if anything about the different design tools listed here but this might be a good place for you to start: http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools#Desktop_Rapid_Application_Development_Tools
SQLite is a great option and will extend your reach to many platforms beyond Windows (iOS, OSX, Android, etc.). I recommend this. If you want to keep using Microsoft products, SQL Server Express or Compact Edition is another possibility.
Another solution, depending on what you are doing with these databases, would be Microsoft SQL Server Compact Edition which does not require an installer.
No matter what database you choose, you are going to be faced with migrating your queries to a different dialect of the SQL language (the actual syntax of your queries). They all have their quirks and features (and missing features). That is just the nature of the beast. It should be noted that you can still access a MS Access database in code without requiring the installation of MS Access.
It appears that the nature of the question has changed dramatically since it was originally posted. The question has apparently morphed into one about finding an user interface development environment that has similar features to Access. This is obviously an entirely different question than finding a replacement for Access (or specifically Jet for those anal retentives in the audience) as a database engine.
There are many alternatives and it depends greatly on whether you wish to continue with a Windows application or whether you wish to move to a browser based interface. Given various comments, it sounds like you may still want a Windows based solution. A couple of solutions you might investigate:
.NET Windows Forms - The .NET environment is incredibly powerful and provides for very rapid development. IMO, as rapid as Access if you know what you are doing and far more powerful. However, with those additional capabilities comes additional complexity. No question that jumping into Windows Forms from pure Access development will be daunting but rewarding.
Another solution, which I admit to not having tested myself, but looks promising is Kexi + SQLite which is geared as an open source replacement for Access.
If you considered changing gears and switching to a browser based approach, there are again many choices. PHP, ASP.NET (MVC and not), Ruby and so on. As with Windows Forms, switching to browser based development from Access development will be a daunting change but also rewarding.
Of course, if the PHB are eliminating Access as a cost cutting move, you could split the existing Access databases to Front-end/backend applications, migrate the backends to SQL Server Express edition (free) and have the users use the MS Access run-time (also free) You, the developer, are the only one who actually needs a paid-for full version of Access.
This response comes long after the question was posted--but Google still turns it up near the top of results for 'replace ms access'
You should include MySQL and PostgreSQL on your list of the potential replacements. MySQL supports AUTO_INCREMENT columns, so it might be a better replacement for the Microsoft databases. Also, Microsoft SQL Server Express might be not a bad option. I migrated from using MS Access databases to using MS SQL Server Express in my apps when I was using Microsoft technologies about 10-12 years ago.
I have to develop a new (desktop) app for a small business. This business currently has an Access database with millions of records. The file size is about 1.5 GB. The boss told me that searching on this DB is very slow. The DB consists of a single table with about 20 fields.
I also think the overall DB design isn't great. I thought to use another DB server with a new design to improve both performance and efficiency.
Considering this is a relatively small business, I don't want to spend much for a DB license, so I want to ask you what would you do.
Continue to use Access, maybe improving and optimizing the DB in some way
Buy a DB server license (in this case, which one?)
? (any idea?)
Things like SQL Server Express, MySQL and PostgreSQL are available for free, no license purchase necessary.
For improving search speeds, you will probably also want to look at things like what indexes are defined for the table, what exactly searches are doing, et cetera.
2nd the recommendation for Firebird. We've been using it for about 5 years and never had an issue. Cross platform, embedded & server deployments... brilliant. Oh, and Free as in Beer. Mozilla Public LIcense.
Put me down as another recommendation for Firebird. We use it with our commercial Point of Sale product. We have it installed at over 1,000 sites, with databases as large as 40+ Gigabytes. It's fast, stable, simple, easy to deploy, and requires no management.
Your could replace the Access Database with a SQL Server database that will scale well moving forward. You can use SQL Server Express which is free and supports databases up to 4Gb I beleive.
SQL Server Express. Free for database size up to 10 GB.
SQL Server Express is a perfect fit for this. http://www.microsoft.com/express/database/
I warmly recommend MySQL. Its sometimes free and is easy to install on both Windows and linux.
There are also a lots of great free tools to manage its content like tables, users, indexes etc...
I would look into if the big table needs to be broken up into smaller ones(rarely needed, but still) and also what indexes are on it. And for Database software I would recommend PostgreSQL. It is free, easy to use(and I consider it easy to setup, though others beg to differ), and it is fast enough for enterprise applications.
You can take a look at Firebird
Firebird is one of the best database for desktop application and will allways be free.
Some tools exist to convert database from access to firebird.
I also recommend Firebird.
Its key advantages for your scenario are (from top of my head):
embedded version. You can ship it with your application - no separate installation kit needed, no .NET dependencies etc.
later on you can scale seamlessly to the full client-server model. No code changes required.
very small footprint
the entire database is stored in a single file. Much easier to deploy compared with other solutions.
you can have your server on any platform you want: Windows, Linux, MacOSX etc. Of course, you can have your client also on the same platforms but since you mentioned Access, I suppose that you have a Windows application.
no need for server administration. It just works.
I recommend PostgreSQL as well (especially as an alternative to MySQL)
No-one ever seems to mention it, but Oracle also do a free-as-in-free-beer version of their database: Oracle Express Edition (aka XE). It is limited to 1 CPU, 1GB RAM and 4GB of user data but that sounds plenty big enough for your application.
As for your database design, just one table sounds more like a spreadsheet than a database application. Probably you have lots of denormalised data. Splitting those out into smaller de-duplicated tables might well speed up certain queries. However if you only have twenty columns there may not be a lot of scope for tuning.
As for recommendation, the question is, which products do you know? If you have a familiarity with Access then I suggest you try to optimize your existing database. I have worked with Access databases which store several million rows and they performed well enough. After all, there is no guarantee that moving the same design to a different product will automatically make things run x times faster. Another advantage of Access as a tool is that it comes with a built-in front-end tool. If you move from Access you may need to think about re-building your application.
Wow, folks have a lot of platform recommendations for you.
Let me just say this.
If you feel like there are design issues as well as platform issues, why not try the design changes first? These are changes you are likely to make anyway.
If they make no performance difference in Access, you are no worse off, since these changes improve maintainability on any platform.
Then you can try other platforms with the knowledge that you have a solid design, and that you have not wasted any time.
SQLite can also be a candidate.
I would recommand not going with express anything - yep your small but what if the busness takes off and need much higher loads in the future - surely thats the way you want it to go ?? do not want to have to switch db layers / run 2 ..
I would look at MySQL or Firebird (used to borland interbase) both very high quality.
This is something I would like to see while doing my day today programming works, But I've never seen such application yet. You input is highly appreciated.
Lets say we have an application that needs MSSQL server as DBMS. And suppose you just need to install it and do something. (i.e You are not going to deply it in production servers etc.)
In such a case it might be an overhead, of installing MSSQL first. I am suggesing something like a software bridge that can use another DBMS to store data. In other words the application "sees" an MSSQL instance but underneath that it might be Access. The bridge sholud do some sort of conversion.
Another example : You have MSSQL but a certain application needs Oracle. You have to purchase Oracle then. But with a something like a bridge, You can put information into your MSSQL DBMS. The bridge listens to port 1521 like Oracle so application "Thinks" there is an oracle installation.
Is it an idea that cannot be implemented?
Are there any such applications?
If so what are they?
Thanks... :)
Adding a Clarification : The application might be from a third party. You don't have any knowledge on internal architecture of that. you just know it uses a certain DBMS. I am trying to use a different DBMS other than the third party software needs.
Application usually don't depend on a specific database server, OR they depend on it for a reason.
If an application asks for oracle, or sql server, or whatever, it's because it relies on the implementation details of this specific vendor to run its SQL, its stored procedures, etc. There's no way you could emulate that with an access database, for example...
If your application just needs to run some very simple SQL (ie basic insert/select statements), it probably uses a standard driver (odbc, ado, etc.), and those drivers can accommodate every major sql database engines. In my experience, "simple applications" don't ask for a specific database vendor.
This is the problem that ODBC was supposed to solve :-) .
But in response to your questions:
Is it an idea that cannot be implemented?
It can be implemented.
It would be tedious and thankless work, and you would have a very limited audiance. In my opinion it's not worth doing.
Are there any such applications?
None that I know of.
If so what are they?
None that I know of.
......
Bringing in Chandrasekar's note in the comments section:
Have a look in a super user's perspective... He has a nice application but he can't use it without some DBMS. But still he is not a programmer to do something. So they need such a product
I agree it has applications, but it has a very limited audiance :) .
What you're proposing is something like the firefox plugin 'ietab', Only you won't have ie installed... so instead of embedding ie, you would need to entirely re-implement ie using firefox's rendering window.
Just my opinion : that's too much effort... It's simpler to just install a second database.
If this application uses ADO to connect to SQL Server and you can modify the connection string, then it's quite easy to use a different database: change the connection string! However, the other database must be able to support all features of SQL Server. Besides, the software was never tested on another database so the application might Crash & Burn.
If you can't change the connection string, or the application doesn't use ADO, things are more complicated and very close to impossible.
I've worked in the past on a project that needed to be reasonable database-independent. The database had to support stored procedures but there weren't any other restrictions. By default, we tried to support both SQL Server and Oracle. (We also supported Interbase but never advertised this.) While we did manage to keep it mostly database-independent, we did have to work around quite a few minor issues. Especially joins in our queries had some nasty problems which we just solved by adding more logic to stored procedures.
"This is the problem that ODBC was supposed to solve :-) ."
And it is the very same problem that SQL was intended to solve too.
It seems to me that the reason why this problem exists is that the world seemingly fails to agree sufficiently on what the data manipulation language/interface ought to look like.
I suspect that if this were solvable, it would already have been done.
The closest I've heard is EnterpriseDB where they have built a layer on top of Postgres so it looks more like Oracle.
But remember these databases have features covered by patents and copyright so there's a limit on how closely a competitor product can imitate the real thing.
It would probably be easier to imitate 'down' than up. For example, MS-Access wouldn't be able to imitate much of the functionality for Oracle or SQL Server, whereas there's a much better chance of SQL Server imitating a simpler DB like Access.
Applications usually DO depend on a specific database server. Every database implements things slightly differently - even MSSQL and Sybase, which have a common ancestor.
Any bridge, however well it attempts to abstract the differences, would leave some exposed. These would be likely to create subtle bugs in the application, which might appear initially to work, but then fail, or worse, corrupt data.
Moreover, the application vendor would not support you in such a case - they'd simply say they don't support that use case, and you should remove the bridge and install a proper instance of whatever database it was intended for.
In short, I don't think it's worth the risk of the application malfunctioning subtly, and being left without support, even if the application isn't especially important. If you dislike the underlying database the application uses, choose a different application.
I am creating a desktop app in Delphi and plan to use an embedded database. I've started the project using SQlite3 with the DISQLite3 library. It works but documentation seems a bit light. I recently found Firebird (yes I've been out of Windows for a while) and it seems to have some compelling features and support.
What are some pros and cons of each embedded db? Size is important as well as support and resources. What have you used and why?
I'm using Firebird 2.1 Embedded and I'm quite happy with it.I like the fact that the database size is practically unlimited (tested with > 4 GB databases and it works) and that the database file is compatible with the Firebird Server so I can use standard tools for database management and inspection. Distribution consists of dropping few files in your exe folder.
Simultaneous access from multiple programs is not supported but simultaneous access from multiple threads is (as long as you ensure that only one 'connect' operation is in progress at any given moment).
I have used SQlite3 for a lot of projects (but from C/C++ and Objective-C). It's extremely small -- no dependencies whatsoever -- database is in a single file.
It's the db of choice for Mac developers because it's directly supported by CoreData and on the iPhone -- so there is a big user base (not to mention all of the other users).
I've been using SQLite (via DISQLite3) in FeedDemon for several months, and I highly recommend it - it has been extremely fast and stable. As Javier said, the docs for the library may be thin, but the docs for SQLite itself are very good.
I've used DBISAM on a number of projects. It is completely embedded without even a need for an external DLL. Unlike the others you listed it is commercial. A lot of great features though and very well documented and supported. The have a successor to it that I haven't tried yet though.
Let's see, quick comparison:
SQLite:
dynamic typing in the database
cross-platform files
runs on Windows, Linux, Mac, etc.
public domain
supports transactions
relies on file system security, does not include own security
Firebird embedded:
strong typing in the database
not all SQL datatypes are supported
cross-platform files
Firebird embedded only runs on Windows
Files from Firebird embedded are in the same format as the full server version
Files from Firebird embedded can be copied to a non-Windows server for use
available under a modified MPL ("what's ours is ours and must remain free, what's yours is yours and you don't have to release it")
supports transactions, triggers, etc.
MySQL embedded:
support for SQL features depends on file format
(IIRC) cross-platform files
GPL unless you pay royalties
runs on Windows, Linux, Mac
incredibly popular with the open source crowd
Even embedded databases have their strengths and weaknesses. You'll need to weigh those strengths and weaknesses against what you're doing to decide.
Firebird embedded is our #1 choice because with no code changes, a single user Delphi app with embedded database can be migrated to a multi-user server based deployment without sacrificing any of the high end features (such as stored procedures, triggers, views, etc.). And its a TRUE free database and doesn't GPL your code in the process.
Strongly recommend to use AnyDAC when working with Databases and Delphi - then you can choose to target FB or SQLite seamlessingly.
My preference would be for FB for embedded apps.
Tom
I use Sybase's Advantage Database Server, but I'm also the R&D Manager, so this post is biased. :)
We have native Delphi TTable and TQuery components for both WIN32 VCL and VCL.NET. Direct table access in addition to SQL support makes Advantage unique among many of the other Delphi offerings. Advantage supports large tables (only limited by the number of records, 2 billion) and has a free local engine, which is nice for development PCs and for small customer sites that don't require client/server functionality. Switch to client/server with a single connection property, no other changes.
We have a ton of clients so accessing the data outside of Delphi is also very easy (.NET data provider, ODBC, OLE DB, PHP, Perl, JDBC, etc).
Main Product Web Site: http://www.advantagedatabase.com
Developer's Web Site: http://devzone.advantagedatabase.com
It really depends what you need. For single-user applications, Firebird Embedded or SQLite are probably best choices (and price is right). On the other end, if you need support for large number of multiple users, you should probably use regular Firebird instead of Embedded version (server is simple to install so you won't have much problems here).
And if you need something in between, for a moderate multi-user application, one of flat databases would be better. I found that ComponentAce's Absolute Database better choice for my needs than DBISAM, NexusDB or VistaDB.
It leaves relatively small footprint (no DLLs), it's a single-file db (a must for me), supports Unicode, BLOB compression, crypting, and technical limits seem impressing for a flat database. Moreover, support was good in few occasions when I needed it.
For cons, I have noticed it doesn't support nested transactions, but other than that, I had no problems.
As for size, nothing beats SQLite.
when you refer about lack of documentation, i guess it's doc for DISQLite3. The SQLite docs are quite complete
Take a look at NexusDB. Have used very successfully in the past.
The problem with (embedded) firebird is, that the database cannot reside on a network drive. Also, it is difficult to have a database on a read only drive (CD/DVD).
For some hacks around these limitations see the Delphi Wiki:
http://delphi.wikia.com/wiki/Firebird_tipps
NexusDB offers the full range from embedded, to full client/server / remote. Also SQL2003 compliant, I believe. I'm using it on a few projects, and am very pleased so far, and the fact that it can work in such a wide range of "scales" is a big plus (not having to learn another DB for scaled-up apps, etc).
Look at this embedded database comparison: http://sql-db.cz.cc/, it can be helpful. Most of abovementioned products are presented there: Advantage, DBISAM, Firebird, MS SQL Server, and much more: Accuracer, Apollo, ElevateDB, NexusDB, TurboDB.
I am partial to Component Ace's Absolute DB. Although a commercial product ($), it is solid, easy to use, small footprint and well documented. If you are looking for a huge multi-user application, this is not the way to go, but if your multi-user needs are light (or non-existent) this is a solid option.
I'm using SQL Server Express and the ADO components. Works great. You can run the SQL Server Express install with commandline to hide the complexities from the users. You can also distribute a database that you load by filename. There are millions of SQL server users so solutions to any problems are easily found in the intertubes :-)
I did a websearch to find a fast database package for my Delphi Application. I wanted it to be completely contained in the executable with no external DLLs or libraries required. I originally found Accuracer by AidAim. They had posted how fast their database was and even gave comparisons with other similar packages to “prove” their point.
I wanted to believe their claims but I thought I’d search the web a bit more to find timings of other packages. I was very surprised to find a post at the Delphi discussion forums where a person asked what database to use, and there were 14 different suggestions. One of the responders had done his own timing comparisons and had found Accuracer to be quite slow compared to several others, which Accuracer had (conveniently) left out of their own comparison page.
The post, plus additional followup web research by me, led me to lean toward DISQLite3, a product based on the Open Source SQLite program, but with enhancements to work in Delphi very quickly, with very small overhead, and with command-based calls - which I like. It is actively under development and will soon have an official Delphi 2009 version, although apparently the current version will work under D2009.
Addenum: DISQLite3 Version 2.0.0, released Nov 17, supports D2009.
I know MS access is a comparatively crap db (and expect to be shot down in flames here), but if only small data is needed it may have advantages if ms office is used anyway. For me it was a way to store program data with more flexibility than csv files which is a common approach for scientific code.
You can create an access db from delphi code without having ms office installed using ado & odbc driver (might be necesary to have an initial .accdb file without tables to copy from then populate, I can't remember this detail. not sure licensing situation doing this.
The .accdb extension can be changed to something else & the file password protected (to a limited degree) so its not immediately obvious to users its access if that's desired.
I know a few commercial developers do this method & copied it myself. Found it easier to setup than sqlite, but maybe because I'd already used ado & access in the past.
I have used ScimoreDB. It has its quirks as they give it royalty free and it has its quirks in data types and with some installation issues. This was on a C# project.
If embedded is an absolute must, look at DBISAM.
kbMemTable is a good candidate. Runs in memory, fast, multi-threadding. Used to be free.
Components4Developers
I have used DBISAM and kbMemTable on different occasions.
What I like about DBISAM is that it has great features, and is usually very reliable. I have used it in large databases, full-text search, read-only mode, CGIs and many other situations.
It is fairly large compared to kbMemTable or SQLite based components, though. And you can't have a single file per database (or even table) - depending on the situation, that is a major disadvantage.
kbMemTable is tiny and it's great for small amounts of data. Since it runs in memory, it has to be a small amount of data, of course.
One other option I've taken on a couple of my desktop apps is dumping the data directly from/to my object hierarchy using TWriter/TReader. This is by far that smallest option, and is absurdly fast compared to using a database. The data files are tiny, too.
It has all kinds of drawbacks, though - you have to code versioning in if you might want to ever add/change fields, unless it's in-memory it is even more complicated, no multi-user support at all, etc.
Firebird embedded is our #1 choice as well. And the suite Unified Interbase v2.0 with it. A great and stable solution!
I have a database that I have to record 5 field data for every 20 sec for 10 days.. 3 field are integer , 1 field is double ( time ) and 1 field is string[5].
I am still using Delphi6 srv2 because of my components. Newer delphi versions are terrible at components that I have to spend thousands of dollars of money to rebuild my component library. Therefor delphi 6 is still best for real commertial applications that never version of delphis give many problems. At many points such as USB or comport readings so on... they release newer ones before previous versions never sit on market.
I have setup a code with Delphi6 what appends 43200 records at a table for test because I will deploy the table in application while it has 43200 records. I will shown all the data on DBChart.
Test result is below databases filled the tables by insert command with 43200 records
Dbisam = 34 sec,
ElevateDb = 11 sec,
AbsoluteDB = 45 sec,
SQLlite = 32 Minute,
Firebird = 12 min,
MSSQL12 localDB = 28 Minute,
Easy table = 8 minute,
BDE = Blocked ,
I havent tested oracle , blackfish , sysbase, nexsusDb etc.. but it seems they will also very slow. I have connected with DBChart and only elevateDb and absoluteDB has loaded 43200 records on DBchart in exceptable time such as 7~10 secs. Other all taken minutes. So slower databases always needs coding tricks to succeed in some real jobs..
I have tested their search speed as well by locate command that unfortunatly the server based databases are always slower in.
MSSQL and SQLLite3 are extremely difficult to manage in to delphi that they made me very tired.
These are my test results
At the end I decided to use AbsoluteDB, Dbisam and Elevate. I have thrown the rest off the PC .
Elevate software doesnt support recno function that requires extra codes at runtime to manage. This makes the database slower Other bug is with Elevate software is autoinc fields. There is no way to reset it . Therefore I have not chosen the Elevat software even it is the fastest database. They say many good functions but how many of them we use it in fact . They just left the most important functions not supported but fixed many many unnecessary functions. and it seems since 8 years there is no any advantage either.
If you want to see with your own eye pls just try and see..
I am thinking between two now absolute DB or DBisam4
Firebird all the way. Does pretty well everything and so far version 2.1 is very solid.
FireBird offers the opportunity to scale up to multi-users sometime down the line, or if you need concurrency (if your application goes multi-threaded).
SQLite is quite unrivaled if you only need single-user access, no other database comes close to it on any aspect, be it performance, convenience, SQL support or stability.
Firebird is really awsome and has a small footprint so you can use embedded
and it can be scaled upward for many users
and does unicode faily well
I use devart components with delphi 2009
and FIB plus for delphi 6/7 (their version for 2009 and unicode is not ready yet too bad)
Hmmm, no one has recommended the BDE - I wonder why that is ;-)
BlackFishSQL is another possibility, although I haven't tested in depth as yet.
when it comes to embedded databases the first question is : is it multiuser ?
Actually,who needs a database that does not allow multiple connections (read&write) to it ?
I have tried (intensly) all mentioned databases and found only one that actually functions the way it should. And that is Accuracer.
The only pity with accuracer is that its a three man band and chronic lack of proper support. It also is mainly static in development as we have seen no real features in years.Not surprising since only one person actually develops it. It seems they are living on old fame. Users praise reflect that (usually 10 years old comments).
For a single user experience I would recommend Absolute Database.
As for major players I would recommend SQL Server from Microsoft. Oracle has become a bloatware and is slowly dying out.
ps
what is nice in accuracer is that their embedded database functions just like full blown server. It locks only current record if its in use while the rest functions normally. Nice database. Pity only it is stagnant.