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
Related
I have deployed plenty of software to my clients. Mostly are Window Forms applications.
Here is my current practice.
Manually install SQLExpress and SQL Management Studio to each client PC.
Then use ClickOne to install the code from the server.
When there is a changes in code, I will use ClickOne to deploy -(NO PROBLEM with this step)
But when there is a change in a database column, what do I do?
I have even tried writing a database update script. Each time the program starts, it will read through the .sql update file and run them if the database exists. This solves the problem of updating the database columns, but it does not help in my DEBUGGING work when my customer complain there is a wrong data. At that point, I have to personally go to their site to check it out.
I find it difficult to have the database installed on the client PC as it make my debugging work very very difficult. I am thinking about moving my client database to a host on an Online server. But that then comes with these constraints:
What if the internet is down?
What if my customer has no internet?
Could you help to advise me? Is this a common problem faced by developer? What is the common practice out there? Does Window Azure or SQL CE help?
Depending on the data I would recommend using SQL CE.
If the data isn't too much, speed is not the primary goal (CE is slower than Express) and you don't need DB-Features not supported by CE (e.g. stored procedures) it is the better choice IMHO, because:
The client does not need to install a full SQL server (easier installation/deployment)
You do not have problems with multiple SQLExpress instances
Your SW doesn't need to worry if there even is a SQL instance
Less resources used on the client side
Additionally the clients could send you their SQL CE DB-File for inspection and you do not need to go to their site.
It is also relativly easy to implement an off site sync with SQL CE and MS Sync FW.
Installing one database per client PC can be tricky. I think you have a decent handle on how to deal with the issue currently. It seems like the real issue you are currently facing is debugging. To deal with this, there are a couple ways you could go:
Have the customer upload their copy of the database back to you. This would provide you with the data they have and you could use it with a debug copy of your code to identify the issues. The downside is that if the database is large it might be an issue transferring it.
Remote onto the customer's machine. Observe the system remotely using something like CoPilot. That way you could see what is happening in its natural environment.
There are probably other ways, but these are a couple of good ones. As for using an online database, this is an option but it brings its own set of issues with it. You mentioned a couple. As for Azure, that is cloud-based (online) so the same issues will apply. SQL CE won't help you any more than your current installation does.
Bottom line is that I would recommend you look into the ways to fix your one issue (as listed above) instead of creating a whole new set of issues by moving to an Internet-based solution. I would only recommend moving to the Internet if it was addressing a larger business need (for example, mobility). Doing the same thing you have been doing only online will probably just make life harder.
To recap the comments below since they are so pertinent to the issue, if you are choosing between file-based databases that don't need to be physically installed on the machine, your best choices are probably between SQLite and SQL CE. Microsoft supports SQL CE better but it is a larger package and has less features than the trim SQLite. Here is a good discussion on the differences:
https://stackoverflow.com/questions/2278104/sql-ce-sqlite-what-are-the-differences-between-them
However, the issue gets more complicated when you start looking at linq2sql since that is designed for SQL server. Microsoft does not support SQL CE with linq2sql out of the box, although there is a work-around that will get it to work:
http://pietschsoft.com/post/2009/01/Using-LINQ-to-SQL-with-SQL-Server-Compact-Edition.aspx
SQLite is not supported at all with linq2sql but there is a way to use linq to talk with SQLite:
LINQ with SQLite (linqtosql)
This library also supports other common databases including MySQL and Firebird.
You could use the SQLCMD utility to execute the change script, as mentioned in this related question
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.
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.
I have a simple app written using SQL Server, Entity Framework, C# and WCF. When I wanted to share this app with my friends, I realised they didn't use SQL Server on their machine. I could go for SQL Server Express edition, as the usage of my app is personal and non-commercial.
I found MySQL as a popular alternative to SQL Server.
1) Would I be required to update my entities when moving to MySQL?
2) Should I anticipate code changes in my BL layer due to change in entities layer? (I am wondering whether entities was built for SQL Server)
Are there any databases similar to MS Access that is lightweight compared to MySQL?
Are there any databases that need not be installed but can be copied around like MS Access?
Appreciate your response!
Sounds like you want SQLite.
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
Very easy to deploy. Also, check out System.Data.SQLite.
According to the System.Data.SQLite page ...
Supports nearly all the entity
framework functionality that Sql
Server supports, and passes 99% of the
tests in MS's EFQuerySamples demo
application.
You should be good. :)
Im not sure how your BLL looks like and i have no experience with entity framework, but ive experienced multiple times that linq-to-sql works much better with sql-server as with any other database.
So unless you have a good reason not to use sql express, i'd advice to stick to sql express.
After all, you should always install something when deploying (unless you use xml as storage, which is quite well possible with linq-to-xml).
VistaDB Express Edition is also free for non-commercial usage and integrates good into .NET and VS. afaik it also works on a single local data file thus requires no specific installation on your friends' computers.
Otherwise I recommend using PostgreSQL over MySql since it is more standards compliant and has a nicer license.
I think what you're after is just a change in providers. What you need to use MySQL is the .Net Connector which supports most everything simple. It's not very mature yet so something very complex you may have issues on, but it should do most of what you want through Entity Framework.
With Entity Framework yes you can do updates, it's LINQ-to-SQL that doesn't update against any other databases (unless you use a third party provider like DotConnect)
SQLite is one alternative, but since multiple threads against it can cause major issues with it's operation, so if you need a major data store I'd go SQLExpress or MySQL.
Yes, you could use MySql with EF but I don't know if it would require changes.... I wouldn't be surprised if it does though. At the very least your physical DB would have to be ported / converted to MySql and that will take time.
I would assume that if you need to install a DB on your friends Pc's why not stick with SQL Express since you already developed in SQL Server on your box. Should be less issues with this than migrating to MySql.
I'd also vote for VistaDB 3 as it's so easy to deploy.