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
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
As a beginner in C#/VS I want to practice making basic LINQ queries on simple DB's. I downloaded the "famous" Northwind and Pubs databases on the official Microsoft websites (https://www.microsoft.com/en-us/download/details.aspx?id=23654). It gave me a .msi files that installed 6 files on my c: instnwnd.sql, instpubs.sql, NORTHWND.LDF, NORTHWND.MDF, PUBS.MDF, PUBS_LOG.LDF.
When I launch Visual Community 2015 and simply make an "Open => File..." and open the "instnwnd.sql", it opens the .sql file without problem. The problem is when I'm trying to make a connection to the database, being either through the Solution Explorer (Data Connections => Add Connection) or while I'm trying to create an EDM (Database first), which is what I want to do eventually.
The exact problem is that one : the Northwind and Pubs databases doesn't show up in the database list when i'm trying to add a connection, I only get the system databases. Here is what I get :
http://img15.hostingpics.net/pics/128870screenshot1.jpg
I read many MSDN documentation pages and several StackOverFlow topic about the matter (the closest of solving my issue was that one, but didn't work :How to connect to LocalDB in Visual Studio Server Explorer?). I have SQL Server Express 2014 with tools, started SQL services in my Windows Services etc.
What should I do in order to have those databases available so I can generate code and starting making my LINQ exercices ?
Thanks in advance !
You need to attach the databases before you can see them**. You're having a problem attaching the databases due to versioning (which is odd), but your sample db's are very old. Perhaps try newer ones from here https://northwinddatabase.codeplex.com/ and make sure you attach them before expecting them to show up in the tools.
** Technically this is not true. I believe there is a way of connecting to sql server and passing a file path in the connection string, however this will likely still fail for your due to the error you get trying to attach the dbs you have. Additionally, it requires a specially crafted connection string which may or may not be usable with the gui tools you're trying to use. It is also, in my opinion, a less common way of accessing sql server databases, so I would stick with attaching them first. If you want to find out more about this, I believe the feature you need to research is called 'sql server user instances'.
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
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.
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.