which db is good Access or SQL when it comes to small inventory system?
SQL requires SQL server installed on client machine but do access requires anything or just dotnet framework to work properly
SQL Express with Entity Framework 4 is a good combination for easy C# development and deployment to client machines. There's also SQL server compact.
MS Acces should be sufficient for small databases.
Obviously there are a lot of differences between the 2 (triggers, stored procedures, user defined functions to bearly even scratch the surface). But for a small data store/app MS Access is fine.
Once you start to look at transactional requirements, and heavily performant database queries, you will haev to move away from MS Access.
If the system where you are installing the application doesn't have the full version of MS-Office (MS-Access) installed, then you will also have to install the MS-ACCESS Runtime which is available from Microsoft website here
If your data needs to be accessed by other applications in the future, MS-SQL or MySQL might be a better choice. Accessing data from Access might not be so straightforward from non-microsoft platforms.
Another consideration is the number of expected users (now and in future). For a single-user system go with Access as SQL Server would be overkill. SQL Server will handle multiple users better and will scale if the number of users is expected to increase in future.
Small inventory system will be a multi user application anyway.
In this case a centralized data storage is advised. Which means that it's a clear choice - SQL server.
You can User SQL Server Express, it now supports databases up to 10G which is enough event for a small enterprise for a Year or two...
If You want to avoid SQL server installation, use SQL Compact
Use SQL Server or another client-server DBMS. There are plenty of good reasons to do that: scalability, security, ease of maintenance and support. The future upgrade path will also be easier whereas using Jet/ACE will generally limit your options or increase the difficulty of porting to another platform later. You can still use Access for the application even if you use a client-server DBMS, so you needn't give up the things you like about Access.
Related
I created a program using C# (Visual Studio) Winforms. I'm about 60% of the way, and it has been connecting to a .MDB file (MS Access). No issues, all working well.
I was convinced by a programming 'expert'/friend that I should really be using SQL Server Express and it was more suitable to my app, thus I spent about 6 hrs switching the program to SQL Server (e.g. rewriting the variables for parameters and changing some SQL specific code).
I have worked on it and now its about... 85% done and I'm putting more serious thought into deployment and I really think I've made a mistake and deployment is going to far more complex than a basic .mdb file.
Below is some details about the program:
The program will run in pharmacies in Australia. It cannot be web based due to specific online uploading medical info that I don't want to deal with, therefore I want it to run on a local computer within each pharmacy.
Each 'server' will probably have between one and 7 other computers connecting
The program is not going to be used often. Potentially between 700 and 7000 records added per year! (so size will rarely be an issue).
There is a bit of "update" SQL happening, but really, not masses of new records.
All computers are running Windows
It needs to be installed by the pharmacy staff, not an IT expert.
Setup and install being easy is the priority here.
Now not that this is a good excuse but there are a number of other pharmacy apps that rely on a basic .mdb file and these are much larger companies than mine.
My gut instinct is:
.MDB is just a file, just install the MS Access runtime and away you go
SQL Server is more complex, needs a server setup properly and may be a HUGE deterrant to using my program
I hope that others can read this in the future and get their own idea on a choice between .mdb and SQL Server in the future!
PS: deployment for .MDB: create a SHARED folder on the server computer. I was told this is going to be complex. Is that correct?
A file based system like Access can work well if you load is light and in general limited to say 5 users (this sounds like about 90% of your example cases). Also, you don’t need to install the Access runtime since in fact you are NOT using Access, but using the JET (now called ACE) database engine. In other words given that you program is written in C#, then you don’t have to install Access, but ONLY install the ACE database engine (that assumes accDB file format).
And you can well easy include the ACE database engine as part of your application install. I should also point out that SQL server just writes to a plan Jane windows file and is also subject to corruption. A Bing search of mdb file corruption produces about 70,000 hits. A search for SQL file corruption results in a WHOPPING 69 MILLION hits!!!!
So given such a light workload then using the JET or ACE database engine is a reasonable choice from what you given so far. The idea here that you must use SQL or a server based database engine is a beyond stupid recommendation based on your typical use scenarios you outlined.
I should also point out that you CLEARY stated that a typical install will NOT have a dedicated server running. In other words the station running SQL server will ALSO be used as a general workstation. This ALSO suggests that some sites will have RATHER limited computers. Installing SQL server on such limited workstations will often cause MORE support issues then you gain by using a server based database system. This is really an issues of the right horse for the right course. You don’t use a huge diesel transport truck to deliver one pizza.
Installing SQL server on such machines could wind up causing MORE problems than using a file based database engine like ACE/JET.
However, given that you already changed your code to use SQL server, there are options for silent installs of SQL server.
However SQL server will have to be installed ONLY on one of the workstations. So when your software is to be installed, you likely have to break it down into two parts. This certainly will “increase” the setup complexity of your software. So now a “customer” will have to decide and figure out what station to “setup” as the database server. In effect you going to have COSTLY human time support calls as a result of this choice.
So a few things:
Ignore the advice here about un-reliability of using a file based database. I had multiple clients running 5 workstations and using a file share databases for OVER 10+ years and never one issue. As I noted a simple search on SQL server corruption yields 100 to 1000 times more hits on the internet.
So SQL server as part of your setup will significantly increase your support costs and setup costs. Furthermore such an install will OFTEN require that you enable correct ports on that workstation that is to run SQL server (and the default express install does not have TC/IP enabled for use outside of that workstation).
Also keep in mind that typical pharmacies etc. only have about 2-5 workstations and they RARELY have a domain. Regardless of the “domain” issue, this really means you be using SQL logons as opposed to windows authentication. So this NOW means you ALSO have to setup a user + logon on the sql server (again, not too hard, but these issues are simply issues that have to be taken care of and have to be done is a “user” friendly way – else you chew up valuable human support dollars for a simply silly program install).
If your typical setup was 10 stations and you expected a “higher” workload and data volume then what you given so far, then I would without doubt suggest that you spend the extra R&D, extra setup costs, and extra support costs and adopt SQL server.
However given the information so far, then as an intelligent and well thought out choice, using the JET (now ACE) database engine in a file share mode is a RATHER good choice.
As I noted, you do not need to install Access on these machines and I would suggest that you don’t. You only need the database engine and there is an install designed to be used with Visual studio etc. that can be found here:
https://www.microsoft.com/en-us/download/details.aspx?id=13255
So you don’t need nor want to install Access – you are not using Access but using the default database engine that ships with Access and it been a separate system and download for over 20 years in this industry.
The major compelling advantages of the file share system is zero setup hassles and not having to setup + install + maintain SQL server on one of the workstations.
If you have multiple computers connecting to your database at any given location, I would DEFINITELY opt for SQL Server.
MS Access has a very poor track record to handling / working with multiple clients and is prone to file corruption and other messy issues - it's a file-based solution - not a real database. It might be easier to deploy initially, but it'll be a maintenance/support nightmare in the long run.
If you use a capable installer software, you could most likely install SQL Server Express silently, in the background, using default values, and offer an "expert mode" if someone really wanted to change any of those settings. Check out using SQL Server Express as a dependency in your Windows Installer, and Google or Bing for "silent installation" for SQL Server Express
I have an application (currently in foxpro) that uses about 12 tables that can be networked.
The tables are related in various ways, but not unduely complex - more like a customer ordering system
I want to rewrite it in C# using MS Visual Studio.
The Application is desktop only but with up to 5 users able to access it at any given time.
The question is which DB should I use?
It needs to be:
Easy to install with the application.
Support sharing from up to 3 or 4 computers
I have looked at SQL Express but the sharing issue looks to be fairly complex and installation for SQL on a server computer is required.
DB4O seems to be for more media rich applications.
I am fairly new to C# (and now getting long in the tooth as well) so I need this to be a reasonably painless way to achieve what I already have in Foxpro.
Some may ask why change - well, there are things that we want to be able to add in the future that would stretch Foxpro too far.
I have spent a couple of weeks researching this and now would really appreciate any help that people could offer.
My policy: If the job can be handled by SQLite (for .NET one option is System.Data.SQLite), use that. On the surface, it sounds like this can.
SQLite is [...] a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain.
Just to stir the pot a bit, if you're connected to the internet you could give a SQL Azure Database a whirl.
No server required; multiple connections not a problem; scalable; maintainable; etc. Synch it with a local database later if you change your mind. MS has a 90 day trial run which would probably suit your investigative purposes.
Downsides are well-covered elsewhere, but mainly it's that internet outage renders your app offline.
It's actually not a bad option if you're looking to get your upgrade up and running quickly.
try MySQL, i think there is an easy way to make the database shared along the network (i think it's in the installation process)
mysql... use this driver ODBC drive so that your .NET applications can connect to mysql mysql odbc driver
SQL Server Compact Edition supports multiple clients on the same machine. If you need to connect to the database from multiple computers, you should probably stick with Express Edition.
Have you considered using a Document Database rather than the typical Releationl Databases being discussed here?
One that is very friendly in the .Net space is RavendDB.
Work through this simple "Hello World" tutorial (shows some basic CRUD coding) in Visual Studio to get a feel for how it works: http://ravendb.net/tutorials/hello-world
LocalDB would be a good solution
Ok before I explain... I know Access should basically not be used anymore.
My application now uses access for its portability.. its an internal application and makes private/internal database storage a snap.
Problem is, it uses JET 4.0 which is not supported in 64 bit operating systems and is frankly not very well implemented anymore.
I am developing using C# .NET visual studio 2008. I am looking for a way to do this with some other database type that would not require me to install anything else on a users computer. I looked into sqlite but there's no easy way to implement it in visual studio
An Ideas?
You can use SQL Server Compact 3.5 (the embedded version of SQL Server 2008).
I recommend System.Data.Sqlite (http://sqlite.phxsoftware.com/), a managed, open-source ADO.Net wrapper around the open-source Sqlite database. No installation required - you just include the single DLL in your solution. It boasts a small footprint, encryption, and good performance.
SQL Server Express edition should come with Visual Studio. It is an option at installation time, IIRC.
Access has a couple of key characteristics:
- Single-user
- Requires installation
For alternatives this gives you (at least):
SQL Compact (doesn't require installation, single-user)
SQLite (doesn't require installation, single-user--although multi-user is supported)
SQL Express (multi-user, requires install)
SQL CE is a good option as already mentioned. You could also consider xml if the data is not private and you don't have concurrent users (which is very likely if you are using Access). Xpath provides a lot of the features you would normally need from database queries and storage. You also wouldn't need to install anything.
Did you try with H2?
The main features of H2 are:
Very fast, open source, JDBC API
Embedded and server modes; in-memory databases
Browser based Console application
Small footprint: around 1 MB jar file size
Check out about implementation:
http://www.google.ba/search?sourceid=chrome&ie=UTF-8&q=C%23+h2+database
This is one reason why people continue to use Access. Of course you want an easy solution that doesn't require any installs on the client side.
We've all assumed so far your users are disconnected from your SQL Server. If they can connect, you're home free. It's less of a problem if you need to support read-only disconnected use, more of a problem if you need to pull updated data from disconnected users.
Can you tell us more about what you need?
Firebird can be a very good alternative to Access and have very good dot net driver
Here is a comparison between Firebird Embedded and SQL Server Compact Edition
How about XML? Easy to use, and it works on any platform. Not the easies to implement if you're unfamiliar with it, but it's pretty rad once you learn how it works.
I am starting one POS (Point of sale) project. Targeting system is going to be written in C# .NET 2 WinForms and as main database server We are going to use MS-SQL Server. As we have a lot of POS devices in chain for one store I will love to have backend local data base system on each POS device.
Scenario are following: When main server goes down!! POS application should continue working "off-line" with local database, until connection to main server come up again.
Now I am in dilemma which local database is going to be most adoptable for me. Here is some notes for helping me point me in right direction:
To be Light "My POS devices art usually old and suffering with performances"
To be Free "I have a lot of devices and I do not wont additional cost beside main SQL serer"
One day Ill love to try all that port on Mono and Linux OS.
Here is what I've researched so far:
Simple XML "Light but I am afraid of performance, My main table of items is average of 10K records"
SQL-Express "I am afraid that my POS devices is poor with hardware for SQLExpress, and also hard to install on each device and configure"
Less known Advantage Database Server have free distribution of offline ADT system.
DBF with extended Library,"Respect for good old DBFs but that era is behind Me with clipper and DBFs"
MS Access
Sqlite "Mostly like for now, but I am afraid how it is going to pair with MS SQL do they have same Data types".
I know that in this SO is a lot of subjective data, but at least can someone recommended some others lite database system, or things that I shod most take attention before I choice database.
SQL Server Compact
It's designed for embedded devices (i.e. Windows Mobile), but can also run on PCs. It's 2MB, runs in-process, single database file, that can have whatever name you like.
Its meant as a local high-performance database. You can't connect to it remotely, and doesn't support stored procedures, or user-defined functions.
But to answer your actual question: how to choose?
Choose what have management tools, with an easy, compatible, upgrade path when you outgrow it.
I'm doing much the same thing: central server probably running MS SQL server and distributed systems though these are running Linux. We opted to do the data transfer in XML and use sqlite on the distributed systems.
It's early days but seems to be going well so far.
There are .net bindings for sqlite.
The reason we chose sqlite were:
because it doesn't need any database management, which would be tricky on the remote systems.
It seems very widely used: for example firefox uses sqlite for local storage.
We can use it on Windows and Linux.
It's supposed to be good at not losing data if there's an unexpected power outage.
I would suggest Sql Compact Edition as it's lightweight and free, so it solves two of your three problems. I have no idea if it works on Mono.....
I've used it in the past, and I was actually quite impressed with the performance. The one big drawback is the lack of stored procedures...
I use System.Data.Sqlite, which is an open-source ADO.Net wrapper around Sqlite from http://sqlite.phxsoftware.com/. You can use it from within Visual Studio to build databases. It supports a subset of the field types of Sql Server, and writing an interface class between the two databases should be a snap. And you get the benefits of simple deployment by including a single DLL in your project and a single-file database. And it includes encryption, too.
How can I release a winform application to a user that takes advantage of a local sql database. I would assume that I need to install the database during some kind of setup phase, but is this kind of thing possible? Is there a free version of tsql that can be used in this way? Mysql?
TSQL is a language specification, not an actual database.
If you're talking about MS SQL Server, it is possible to bundle and install an instance of SQL Server Express, if you want to distribute a database with your app. There's some documentation on it over on MSDN, specifically, Embedding SQL Server Express into Custom Applications.
SQL Server Compact Edition is suitable for this. It has some limitations in that it does not support the full set of functionality that SQL Server supports (ie. stored procedures is one example), but it does mean that you don't need an installation of SQL Server to use it. If you are only using the database as a "bit bucket" to store and retrieve data, then it should suffice.
Another alternative is to use SQL Server Express Edition. This does require installing a proper SQL Server instance, but basically gives you a cut down version of the full SQL Server, enabling you to use more of its features.
Both of these are free.
You might also want to check out VistaDB. It is syntactically compatible (although not perfectly) with sql server. All managed code. But it is not free.
SQL Server Compact Edition does not support stored procs, fyi. But is a single file deployment plus your data file.
SQLite is extremely fast and lightweight. Deployment is single file plus data file. But it has some syntactic limitations and has limitations to its dotnet integration (although I am pretty sure there IS a ado.net provider for it.)
I support an application built on sql express edition and it is a PAIN. It has a lot of install failures. (Probably about 10k installs over the last 3 years.) But if you need to power, hot backup, full sp and function support, connection pooling, etc it will work for you.
Never used mysql so I can't comment.
Seth