Which is better (and for what reasons) to use to connect to MS SQL, Oracle or Firebird from a Delphi Win32 application -- ADO or DBX (Database Express)?
Both allow you to connect to the major databases. I like the way ADO does it all with a connection string change and the fact that ADO and the drivers are included with Windows so nothing extra to deploy (it seems, correct me if I'm wrong).
DBX is also flexible and I can compile the drivers into my app, can I not?
I really am keen to have a single source if possible, with the ability to vary databases depending on the customer's IT department/preferences.
But which is easier to program, performs better, uses memory most efficiently? Any other things to differentiate them on?
Thanks, Richard
ADO is simple to use and is there, you only must make sure to install the correponding client driver in the client side.
I found DBX more flexible and it is better integrated within IDE and another technologies like DataSnap.
For the same purpose than you, I have used DBX with Third Party Drivers from DevArt.
You can compile the drivers with your application if you buy the drivers sources.
In the beginning of Delphi, people praised the multi-DBMS support in Delphi. Everyone loved the BDE (because that was the only way to do that).
But when looking at customers over more then the past decade, I have seen a steady decrease of multi-DBMS support in their applications.
The cost of supporting multiple DBMS from one application is high.
Not only because you have to have knowledge of each DBMS, but also because each DBMS has its own set of pecularities, where you have to adapt for in your data access layer. These not only include differences in syntax and underlying data types, but also optimization strategies.
Also, some DBMS work better with ADO, some better with a direct connection (like skipping your Oracle client all together).
Finally testing all the combinations of your software with multiple DBMS systems is very intensive.
I've been involved in a few projects where we had to change the DBMS backend and/or the data access technology (from i.e. BDE to DBX, or from DBX to a direct connection). Changing the backend always was much more painfull than changing the data access technology. Multi-tier approaches made them somewhat easier, but increased the degrees of freedom and therefor the testing efforts.
Some of products that I do see that support multi-DBMS are in vertical market applications where the final customer already has their own DBMS infrastructure and the application needs to adapt to that. For instance in Dutch governmental areas, Oracle has been really strong, but SQL Server has established quite a user base as well.
So you need to think about what combinations of DBMS you want to support, not only in terms of functionality, but also in terms of cost.
If you stick to one DBMS, then it makes no sense to go for a generic data access layer like BDE, DBX or ADO: it pays off doing a connection as direct as possible.
My experience has taught me that these combinations do work well:
Interbase or Firebird with FIBPlus, AnyDAC, IBO or IBX*
Oracle with AnyDAC, DOA or ODAC
Microsoft SQL Server with ADO
IBX does not like Firebird very much.
Hope this gives you some insight in the possibilities and limitations of supporting multiple DBMS from your Delphi applications.
--jeroen
General rule: every layer of components will possibly add an additional layer of bugs. Both ADO and DBX are component wrappers around standard database functionality, thus they're both equally strong.
So the proper choice should be based on other factors, like the databases that you want to use. If you want to connect to MS-Access or SQL Server, ADO would be the better choice since it's more native for these databases. But Firebird and Oracle are more native for the DBX components.
I personally tend to use the raw ADO API's, though. Then again, I don't use data-aware components in my projects. It's less RAD, I know. But I often need to work this way because I generally write client/server applications with several layers between the database and the GUI, thus making things more complicated.
My two cents: DBX is significantly faster (on both oracle and sql), and significantly more finicky and harder to deploy.
If performance is a factor, I'd go with DBX. Otherwise, I'd just use ADO for simplicity's sake.
As others have said, DBX may have the edge in raw performance in certain cases or under specific circumstances, but ADO is the basis for a very larger number of applications in the world so although performance of ADO may be relatively poorer, clearly that does not mean "unacceptably" poor.
For myself, and informed by major projects I have worked on, the biggest "problem" with DBX is that no matter how good it may be, it is a key infrastructure technology provided by a language/tools company.
Anyone that built applications on the previous BDE technology will testify to the disruption caused when that technology is deprecated and no longer supported. Whilst no technology is immune from deprecation by it's provider, ADO clearly has the edge when it comes to industry support beyond the technology provider themselves.
For that reason I myself now always use ADO. Just changing the connection string isn't always the only thing to worry about when changing from one database type to another however. Stored procedure call syntax can vary from one ADO provider to another, and you still have to watch the SQL syntax you use if you intend deploying against multiple different SQL engines, where the SQL support may vary from on to another.
To mitigate these issues I use my own encapsulation of the ADO object model. This encapsulation does not attempt to mutate the object model into something that doesn't resemble ADO, it simply exposes those parts of ADO that I need to use directly in a more ObjectPascal friendly (and "type" safe) form (e.g enum types and sets for constants and flags etc, rather than just scores if not hundreds of integer constants).
My encapsulation also takes care of some of the minor variations in different provider behaviours/requirements, such as the previously mentioned differences in stored procedure call syntax.
I should say also that similar to another poster, I too long ago stopped used "data aware controls", which opens up this approach. If you need or wish to use data aware controls and wish to use ADO, then you cannot use ADO directly and must instead find some encapsulation that exposes ADO thru the VCL dataset model.
ADO is Microsoft world
DBX was created at the beginning (Delphi 6) for cross platform and Kylix
Related
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 a project for a class which requires that if a database is used, options exist for the user to pick a database to use which could be of a different type. So while I can use e.g. MySQL for development, in the final version of the project, the user must be able to choose a database (Oracle, MySQL, SQLite, etc.) upon installation. What's the easiest way to go about this, if there is an easy way?
The language used is up to me as long as it's supported by the department's Linux machines, so it could be Java, PHP, Perl, etc. I've been researching and found info on ODBC, JDBC, and SQLJ (such as this) but I'm quite new to databases so I'm having a hard time figuring out what would be best for my needs. It's also possible there may not be a simple enough way to do this; the professor admitted he's not a database guy either and he seemed to think it would be easy without having a clear idea of what it would take.
This is for a web app, but it ought to be fairly straight forward, using for example HTML and Javascript on the client side and Java with a MySQL database on the server side. No mention has been made of frameworks so I think they're too much. I have the option of using Tomcat or Apache if necessary but the overall idea is to keep things simple, and everything used should be able to be installed/changed/configured with just user level access. So something like having to recompile PHP to use ODBC would be out, I think.
Within these limitations, what would be the best way (if any) to be able to interact with an arbitrary database?
The issue I think you will have here is that SQL is not truely standard. What I mean is that vendors (Oracle, MySQL etc) have included types and features that are not SQL standard in order to "tie you in" to their DB, such as Oracle's VARCHAR2 and so on.
When I was at university, my final year project was to create an application that allowed users to create relational databases using JDBC with a Java front-end.
The use of JDBC was very simple but the issue was finding enough SQL features/types that all the vendors have in common. So they could switch between them without any issues. A way round this is to implement modules to deal with vendor specific issues and write ways to translate between them. So for example you may develop a database for MySQL with lots of MySQL specific code in that, but then you may want to use Oracle and then there are issues, which you would need to resolve.
I would spend some time looking at what core SQL standard all the vendors implement and then code for these features. But I think the technology you use wouldn't be the issue but rather the SQL you create.
Hope this helps, apologies if its not helpful!
Well, you can go two ways (in Java):
You can develop your own classes to work with different databases and load their drivers in JDBC. This way you will create a data access layer for yourself, which takes some time.
You can use Hibernate (or other ORMs). This way Hibernate will take care of things for you and you only have to know how to use Hibernate. Learning Hibernate may take some time, but when you get used to it, it can be very useful for your future projects.
If you want to stick Java there Hibernate (which wouldn't require a framework). Hibernate is fairly easy to use. You write HQL which gets translated to the SQL needed for the database you're using.
Maybe use an object relational mapper (ORM) or database abstraction layer (DAL). They are designed to provide a standard API to multiple database backends, making it possible to switch between different backends with minimal or no changes to your code. In Python, for example, a popular ORM is SQLAlchemy, and an excellent DAL is the web2py DAL (it's part of the web2py framework but can be used as a standalone DAL outside the framework as well). There are many other options in other languages as well.
use a framework with database abstraction layer and orm . try symfony or rails
There are a lot of Object relational database frameworks, unless you prefer jdbc. For simple/small applications this should work fine.
All my (home) CF learning has so far been done using Access as a database, and as far as the DB goes I "get it". There's no database server, and no need to log on to the database or anything, and setting up table relationships is easy and visual. Oh and its essentially free to deploy.
However, I'm now working on an application that's likely to be used across several businesses and probably up to 50 concurrent users. I've heard that Access really isn't up to multi user use or production use on an app. What would you recommend as more suitable, preferably easy to grasp, with minimal tweeking needed for my SQL (I used a tool to convert to MySQL and it certainly handles concatenation differently, I dont want to have to do too much debugging), visual interface available, scalable, backupable, and whatever else I need that I don't yet know I need!
I recommend SQL Server 2008 Express. It has a great feature set, graphical UI admin tools, and you can step up easily from it to more commercial solutions as you continue to grow.
You could go with either MySQL or Microsoft SQL Server Express. Both are free and both work well.
Unfortunately you're going to have headaches converting your database no matter what you go with. Microsoft Access doesn't use standard SQL so string concatenation, functions, etc. will be different.
If you're merely using Access as a database, then naturally, Microsoft SQL Server is closest in concept (and SQL dialect) to access.
However, if your focus is on web development, the LAMP stack and specifically MySQL are a better choice. You should at least have an idea of some basic administration.
My experience is that the main challenge is going to be with data types and with string operations (sound like you have similar issues).
Generally, strive to write SQL that is portable, so it's good to read up on things that make it not portable or avoid using special tricks. If you can't do that, then abstract away using code, or even use an ORM tool.
The main benefit of Access, IMHO, is its built in support for generating UIs and reports, while hiding much of the underlying SQL. Most of the Microsoft languages (especially VB) offer similar capabilities. If you've used the UI or the forms, you'll now have to both learn a language or tool for generating UIs/forms/pages, and how to use SQL. Since you mentioned ColdFusion, I'll assume you have most of these skills already.
Before doing anything at all, I'd choose a database abstraction layer and refactor the existing code to use that.
Then it's relatively trivial to swap out your back end pretty much completely ecumenically.
If you use prepared statements, you'll also get protection against many forms of SQL injection.
I would also point out that a Jet/ACE back end was never a good choice for a web-based application because of the mismatch between the threading models and memory management of the web server and the Jet/ACE database engine (though if you use ADO, Jet is reported to be threadsafe; I don't quite understand how you can magically transform a non-threadsafe db engine into a threadsafe one with a data interface layer, but Michael Kaplan said it was so, and he is the type of person you can trust on that type of subject).
I don't have any experience with the Microsoft SQL Server Express, so I can't speak for. However, I do use MySQL with ColdFusion 8 and I'm continually impressed with the capability, flexibility, ease, community support, and speed of MySQL. PHP MyAdmin is pretty straight forward and a good web interface for MySQL. My $.02, spend it how you may.
I'm using delphi for years, but never for database stuff, but recently started researching and testing.
I must say, i'm impressed, most of things happens automatically, i'm used to write by hand in php and python.
i'm going to develop a commercial system for a friend, (2 layers) 5 user computers, 1 database server.
Database server will be a decent machine with (raid-1) 2 hard drives running (MySql5.1 or Postgre or Firebird, open to suggestions).
ADO
Easy to use
Easy deployment (only mysqlconnector installer)
The slower?
DbExpress
Need to ship 4 files [dbxconnections.ini, dbxdrivers.ini, mysqldll, driverdll]
The more complex (harder to use)
ClientDataSet add complexity, but looks really useful
No free Postgre driver?
Zeos
Easy deployment (1 dll)
Easy to use
As you can see the desired features are:
fast
easy to use
easy to deploy
I can't test all in a real scenario (clients, server), so i hope that you guys with experience can help me out in which one to choose and why.
EDIT: Thanks everyone, i think i will go with ADO (probably) or Zeos
Thanks in advance
Arthur
#arthurprs, for you scenario
(2 layers) 5 user computers, 1 > database server.
alt text http://www.techsolusa.com/images/firebird-logo-64.gif The Firebird RDBMS is a very good option , because is very stable, fast, runs on Linux, Windows, and a variety of Unix platforms and meet with you requirements.
alt text http://d.yimg.com/kq/groups/12858579/homepage/name/homepage.jpg Respect to the components for connection i go for ZEOS.
I have used this combination in many small and medium projects, with excellent results.
I have worked on many commercial high volume systems using ADO without any problems. Deployment is relatively simple since its included in the OS. Since it has such a wide audience, most of the major issues have been identified and corrected. Getting help with ADO connectivity is very easy. The database support is very deep (connectionstrings.com) which make supporting additional database engines almost trivial (you may need to still install the client drivers, but that would be the same for almost any solution).
Performance isn't much of an issue, it really will come down to database architecture and engine selection.
id have to say im rather happy with NexusDB but the cost for the client/server versions might not be worth it.
it works client/server or fully embedded, simple enough you can have both in your app and switch between them, depending on your clients needs
the embedded DB is free,
client/server "Priced per developer" is AU$ 500
No cost per install.
Oh yeh and its written in delphi ;)
I'd say to go with Firebird - is the most used database engine in the Delphi land (see here). For connectivity perhaps is better to go with Zeos (free) or DBX (if you can afford the Architect version - the only one who has the Firebird driver in it).
About ADO: Mature connectivity layer but it will be (forever - most probably) tied to Windows while Delphi will go cross-platform. Also, yes, it tend to be the slower one because of many reasons, including the ODBC drivers which are used in certain situations. But in your case, of course, as skamradt says, I don't think that it will matter so much.
Although I have read people not liking the idea of mixing the two, I have had good results using ADO Datasets as a "provider layer" which then feeds the data into TClientDataSets - so there's no reason you can't use ClientDataSets if you go down the ADO route if you find you need them (and they are useful).
Otherwise, I would echo the comment that ADO is a tried, trusted mechanism that isn't going anywhere. I've always found it more than fast enough. And configuration using UDL files is nice and easy.
dbGo (ADO) is more simple to manage, more universal, more slow
dbExpress is more fast, more complex to manage, supports less DBMS's
ZeosDBO is simple to manage, universal like dbExp, slow like dbGo, cross-platform, has few additional components, all sources are accessible
There are few other libraries, resolving all above doubts, although all of them are commercial products. But there I am biased :)
We have used postgreSQL using Devart pg components with great success in medium sized database apps.
We did some limited benchmarking with this combination and found it 2-3 x the speed of using ADO etc.
-- Data access components
I too favour the combination of TClientDataset and ADO. Had worked with it in past and I can say it's trustful. The flexibility of TClientDataset is a big gain. DBExpress is good too.
Actually, I use clientdatasets with pretty much any data access layer that have an TDataset descendant...
-- Server
Firebird. Free and easily usable from OLEDB (I used with ODBC) and DBExpress (D2010+ have native DBX driver) - don't know ZEOS, but I believe that it also connect to FB.
Scale well to many connections and big databases. There are databases on Firebird with 500Gb and many users reported.
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.