I like the simplicity of SQLite, but by design, it doesn't support concurrent access. The apps I write don't have heavy needs, so I'd like to avoid heavier solutions like MySQL that are more difficult to deploy (remote customers with usually no computer personnel).
Does someone know of a good solution that would offer the following features?
Client available for VB.Net applications
The server itself doesn't have to be a .Net application. Actually, I'd rather a bare-metal server so that it can run even on embedded Linux hosts with less RAM/CPU than regular PC's
Easy install: the client part should either be statically linked inside the client application or be available as a single DLL, and the server should just be a single EXE listening for queries, à la Fossil (http://www.fossil-scm.org)
clients can locate the server on the LAN by broadcasting data picked up by the server, so users don't have to write down the IP address and paste it into each client
open-source, or moderately priced closed-source
I would recommend Firebird SQL http://www.firebirdsql.org
Can be embedded and can work as a separate server. Very little footprint with high capabilities.
Have you considered SQL Server? It scales well from Compact Edition (free, file based), through Express Edition (again, free, but requires installation) and then through the paid-for editions for when your product needs to scale further.
HSQLDB is also very leightweight, and the upcoming 2.0 release supports concurrency in form of MVCC. It is based on Java though, but there is an ODBC connector available.
You may also consider Derby... Its free and open source.
Related
Currently, I'm developing a C#-based program for a small rental company (3 locations). Right now, they use MS Access 97 (Jet SQL based) as database and I wish to upgrade this. However, I do want to keep Access as Front-end, since I will be gone after the development, and the local personnel knows how to use Access (some changes require direct editing in the database).
I am doubting between two options:
Upgrade to Access 2013, therefore using MS ACE as DB engine
Use SQL Server Express with Access as front-end, therefore using MS SQL Server as DB engine
The system will have one shared database and one for each location. They are using a shared drive for this (they work on MS Server 2008). Their databases are pretty small (< 1 GB combined), so I won't need the extra performance e.g. MySQL provides. I know the difference between ACE and SQL Server in terms of design (File-sharing vs client/server), but I still don't know what would be better suitable for this situation.
What is the better option here when looking at performance, reliability, security and connection to the application?
Thanks in advance.
As #granadaCoder points out, the security, performance, reliability of using SQLExpress is far better than Jet and ACE and is just as easy to connect/link to your Access 97 front-end. Microsoft provides a free migration tool that is very powerful and easy to use.
Converting an MS-Access 97 application to 2013 may present some real challenges as Cwell. onverting from Access 97 to 2013 is a two step process. You must first convert it to 2002-2003 and then to 2007/2013. You will also need to purchase licenses for all users and the back-end database.
In addition, if your 97 application references external objects, they may not work with later versions of Access.
As #granadaCoder also suggests, a good medium to long term plan would be to convert the front-end to .NET.
Microsoft Jet is just a file sitting on a network drive.
So when you do queries......the Jet-Runtime (on the local PC) has to bring large chunks of data (entire tables) across the network.
Thus it is brutal.
Sql Server (Express or Other)....runs as a service on a host computer. And when a query is executed, it does processing on the Server and returns "smaller buckets of information".
(Which you mention knowing the difference between file-sharing vs client-server).
If you cannot give up your Access(the program) front end...then doing link-tables to Sql-Server would be you best bet, IMHO.
Well, I'm talking from performance.
Security, you have more options for different users and passwords. And you can slice up which logins/db-users are allowed to do what.
IIRC, a Jet database allows one password. Aka, all or nothing.
https://www.connectionstrings.com/ace-oledb-12-0/with-database-password/
That alone would make me go with SqlExpress.
..
The big early design decision was to use Microsoft-Access-Forms. You're paying the price for that early decision.
Even when people use a Jet-Database, I would only use it for basic data storage. And put a Layer .Net application on top of it. Then a swap out to a different data-store isn't as drastic.
Good luck dude.
At the moment I am using Access & an OleDb connection to store data. I went down this route originally because I though that this was the best way for applications that I am distributing to my clients.
I would prefer to use something like SQL Server but is this a good idea for software I am distributing? Does the average Joe's PC have SQL Server pre-installed? If not, I suppose I can provide them with a link to download it for free?
Is there any better alternatives to Access / SQL Server?
You can use SQL Server CE and bundle the database with your application.
See this How to on MSDN.
You haven't really given enough information to answer this specifically but I'll answer generally:
Does the average Joe's PC have SQL Server pre-installed?
No.
If not, I suppose I can provide them with a link to download it for free?
Yes, Microsoft has fairly generous 'free' versions of SQL server Express for small database sizes (<1GB) and small numbers of CPU's (1). Check here.
Are there any better alternatives to Access / SQL Server?
It depends on your app, your skill and how you define better.
If you are running sql-server you can very easily use linq2sql and have strongly typed data base objects that offer clean vb.net code. The linq technologies are worth learning IMO. The tools in VS2010 work well with sql-server databases. Other more modern Microsoft tools are available too that integrate very easily (entity framework and lightswitch (which I don't have experience with)).
For small local databases sqlite works well. If your project is very small and the sql is simple this is a very light weight solution. This is very small and very fast and is used everywhere.
If a server is needed and low cost matters mysqlis a solid open source server though it is now under private ownership.
Again depending upon your application off-site hosting of a database might be a viable solution. I have a client that is still running their db in the cloud with a low cost 2008 SQL Server provider.
When looking for which version of Delphi 2010 to buy, we found the following limitation on the professional one:
Delphi 2010 Professional is designed
for developers building
high-performance desktop GUI and
touch-screen applications with (or
without) embedded and local database
persistence.
What does this really mean? Does this mean that we'll only face this restriction if we choose to use the native vcl components for database access we'll face this restriction.
And what if we choose to use ADO components instead of those? In this case, how can Delphi avoid us to access remote database servers? Did anyone here ever tried this?
Going even further: if we choose to use a database like Firebird, which is just one file, and used a network mapped drive. Could we be facing the same limitation?
Supposing we opt for ADO, what will be the main consequences?
As I understand it, they're referring specifically about dbExpress and doesn't restrict you from using dbGo or some third party library to access remote databases.
Does this mean that we'll only face
this restriction if we choose to use
the native vcl components for database
access we'll face this restriction.
Yes. The professional version simply leaves out some of the driver & driver technology that natively supports certain databases. It still includes ADO support and there are plenty of third-party drivers that you can use to access other databases.
Delphi 2010 does not include any technology to stop you from building applications that interact with remote databases aside from the fact that it does not include DB Express (its own database driver technology).
DataSnap is not included in the Pro version either. I got quite interested at a recent Delphi workshop when they showed off DataSnap only to discover when I got back that it's missing from the Pro version.
So I'm back to sticking with my SDAC components and other third party middleware components. Works perfectly without the expense of the enterprise version.
The SQL Server dbExpress driver isn't included (amongst others) but the ADO/dbGo stuff seems to work just fine over the network. But we haven't used the Delphi supplied DB drivers since Delphi 3 due to them keep changing their mind about the latest silver bullet for DB access (much like MS do/did).
Which of the Database servers would you people recommend for using in a moderate-to-large scale (will vary from customer to customer) application.
I know MS SQL but since the app will be developed using delphi the .net framework is kind of annoying to deploy aswell. Also how realiable is Interbase.
Thanks in advance.
Since I have been developing in Firebird for several years now, if I were in your situation, I would look no further. The fact that you can develop your own extension library (udf library) in Delphi makes it very attractive to start with. Some of the new SQL constructs like the List aggregator and Common Table Expressions are icing on the cake. Deployment is very light (under 5 MB), and the support is excellent including incredible tools like IBExpert. I used MS SQL Server in a big company I worked at a few years ago and I would choose Firebird over MS SQL Server.
Data Access to SQL Server has nothing to do with the .NET framework. Delphi can connect just fine to SQL Server.
In terms of database engines that work with delphi, another you can consider is the Sybase Advantage Database server
Interbase is as reliable as they come. In fact, I'd like to get a job as an Interbase DBA, because I could uses the sleep.
I would definitely recommend looking at Interbase by Embarcadero or the open-source sibling, Firebird. Both are very well supported by Delphi by means of native, high-performance db-access components and such.
Interbase is a totally rock-solid database - I would put it on a par with SQL Server or Oracle. It's totally capable of handling medium to high traffic for at least 50-100 users concurrently, no problem at all.
Another two worth competitor would be Elevate DB and Nexus DB. Both grew out of Delphi file-based database systems, and both have been around for quite some time (in one form or another) and are well proven, widely used, well tested.
Marc
This seems back-to-front to me. I would choose the database server first, then select the development environment that works best with the selected database.
SQL Server. For 2005, you can make your own SQL Server deployment application that automates installing of Windows Installer 3.1, .NET Framework 2.0, SQL Server 2005 then installing the database through generatated SQL script (Feel free to contact me if you need help with it, I'd gladly help you). If you still insist on not installing .Net framework which is 22MB, I'd say go with SQL Server 2000 as you can still upgrade it to 2005+ when you'd like to.
Also, I had been using Advantage Database Server for few years and it's alright, Few DLLs to copy and you're ready to go even if you'd like to switch to remote version.
Both Server and Client installations of MS SQL require the .NET framework on the target machine. That's about it. If we can use ms sql without .net on target machine then ms sql is fine.
I have being developing in Delphi for about 6 years using distinct editions of SQL Server, and this database server behaved very very well. All of them were critical applications.
So, I would recommend you to keep with it.If you don't want to use .NET with and keep SQL Server I would recommend an older version pre-2005.
This isn't really an answer, but some things you might like to consider before making your mind up.
What do you mean by moderate-to-large scale? Do you mean by the number of concurrent users or by the amount of data being stored?
Are you going to be supporting the database as well when it's deployed, or might the customer have their own DBAs and want to incorporate it into their infrastructure team's remit?
Do you need to build-in complex features like auditing or granular security that some databases might provide out-of-the-box? Do you need to be able to run an overnight batch process on the database in some controlled manner?
Do you need to be able to have robust high-volume transactional support, or is it more for just using as a sink for reporting data? i.e. is it more OLTP or OLAP?
Are you limited by cost? i.e. does it need to be free/open-source, or can you select paid-for vendor product?
Both Firebird & Interbase are great, but not generally well-received into an "enterprise" environment in my experience unless they're "hands-off" and embedded into the application. MS SQL Server is a "safe-bet" for most systems. There is a cost associated with it but, as you know, it does come with a complete toolset and very good support.
If you do go down the Firebird or Interbase route then do take a look at Jason Wharton's IBObjects library which provides a high-performance replacement for BDE when using these databases. http://www.ibobjects.com/
I'm looking for a desktop/embedded database. The two candidates I'm looking at are
Microsoft SQL Server CE and Oracle Lite. If anyone's used both of these products, it'd be great if you could compare them. I haven't been able to find any comparisons online.
The backend DB is Oracle10g.
Update: Clarification, the business need is a client-server app with offline functionality (hence the need for a local data store on the client)
If the backend database is Oracle 10g it will probably be easier for you to use Oracle Lite - that way you don't have to use two completely different SQL dialects in the same project.
BTW, In my product I use SQLite as the desktop database
I'll second the vote for SQLite. I'm not sure what you're trying to accomplish but if you're doing any sort of local storage with syncing SQLite is a good choice. It has very widespread adoption and a lot of community support.
I also used SQLite as a desktop database. It's lightning quick and doesn't need a seperate process or any prior installation. All you need is a library to access the data as part of your code.
In light of your clarification I'd evaluate both OracleXE and Oracle 10g Lite before the others. Stick with the same tech, SQL/Oracle have some funny disagreements about SQL syntax and datatypes. I imagine you'd get the same issue with SQLite.
Perhaps I'm not fully understanding the need here. You are developing against 10g, but for your own test/dev environment you want a more lightweight database?
Or, are you developing an application that synchs with 10g database when online, but when offline uses a local store?
In both cases, I'd recommend staying with Oracle only because it will simplify your code.
In the first case, I'd wonder why you don't have a 10g QA machine somewhere that all the developers can connect to.
One advantage you have with SQL Server CE is that it is free and you can use the Sync Framework to syncronize it with any ADO.NET accesible database.
Also, the same SQL CE file is usable from the PC and mobile devices, and if you develop your application using .NET, you can use the same code for the desktop and the mobile device without changes.
You might want to look at Oracle XE. I cannot remember all of the differences, but O-Lite didn't fit my project needs. Oracle XE is a very good database for local development.
Brad
As #Nir mentioned, it's better to have homogeneous environment. However if you decide to not use Oracle Light, I would highly recommend you to take a look at Firebird. It's one of best choices for desktop database scenarios.