Develop Reference

Apply changes to Database later/manually

Is it possible to achieve this?
Download/fetch data from the database then save locally to a Windows Mobile app for later use (without internet connection).
Make changes to the database locally.
Upload the changes of the local database to update the database from the server manually.
I am thinking about a sync function but I am using an Oracle Database on the server and Oracle DB and SQL Server Compact doesn't support syncing with each other naturally.

Sure this is completely possible, but you are going to need to write the syncing feature yourself unfortunately. You might be able to incorporate this, but as of now there is no bolt-on solution for you, so you would need to add the syncing features.
Happy coding!

Please read about the ADO.NET technology.
It was made for implementation of your scenario - maintaining of disconnected cache of server data.
For example look at this article
And here is more specific example -> Disconnected Architecture in ADO.NET

Here's a great walkthrough from Microsoft on doing exactly this:
Walkthrough: Creating an Occasionally Connected Smart Device Application
Note that it was reported that this technique is not 100% reliable, meaning it can "forget" to post the latest data.
To get around this, you can add a TimeStamp DateTime field to each table that stores the time the latest data was written or updated, then modify your queries to only pull/push the latest records.

Database Deployment Practices

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

Switching from using SQL Server Express to SQL Server Compact

So far I have been using SQL Server Express on my desktop application even though usually the server is only used by that single application, by the single user, on the same single machine. This always seemed a bit silly to me since the full-on server is rather heavy.
Then I found out that there is something called SQL Server Compact. Thing is, my application is already rather large. So my question is that if I wanted to change to SQL Server Compact, what kind of changes to my code are we talking about (using C#)?
Mainly I'm wondering if I can access the Compact -version in the same manner as I can access the Express one, which is using ADO.NET and pointing it towards localhost\sqlexpress. So would it be possible to create another instance with the Compact and just point my application to that, or is it used in a completely different manner?

For a standalone desktop product it is certainly a lightweight option to consider over SQL Express.
However there are differences between the two to be aware of other than just connection strings. For example SQL CE does not support stored procedures, user-defined functions, or triggers. Additionally it does not support the full range of datatypes that Express supports. On a technical level it also runs in process with your application.
Another consideration is that while SSMS will work with SQL CE databases, it's not as fully featured as it is with SQL Express. There are however a whole raft of good tools out there for filling these gaps. Take a look at Erik Jensen's blog for a good overview.
Everything SQL Server Compact
Also check out his tool for migrating SQL Express databases to SQL Compact:
How to Migrate/Downsize a SQL Server database to SQL Server Compact 4.0 (and 3.5)
Finally take a look at this SO question for more background between the two products:
What are the limitations to SQL Server Compact? (Or - how does one choose a database to use on MS platforms?)

I worked recently with it, by the way the things I know about using them is that SQL Express has a server to connect to, and, Compact is a sdf file, so the first thing you will have to change is the connection string to it.
After this change, there are no more heavy changes to be done, I remember, compact has almost all the instructions of the express server available, so, it could not be much problem.
Take a look at Microsoft documentation for more information, or at Wikipedia.
See you.

I would vote against SQL CE:
It has no views, which might be an issue when migrating.
We recently did something similar which you described and had tremendous performance impacts when switching from SQL Server Express to SQL Server Compact Edition.
My recommendations would be:
Use SQLite (which we did for the project I mentioned - it was much more performant than SQL CE in our case) -or-
Use VistaDB (which I did in other projects; not as performant as SQL Server Express, but still sufficient)
Both databases can be XCOPY deployed, just like SQL Server Compact Edition.

SQL CE has the same size limitation as Express, so you should be good.
As far as moving between the two, I found this for moving between express databases and compact 3.5 databases. Then I think you'll only have to change your connection strings (instead of pointing at a host/instance, you point at the converted file). There are different features between the two, though, so you might have to change your schema in the original database for the conversion to go smoothly.

Automatically Creating Client Schema with Microsoft Sync Framework

I need to make a local copy of a database in a .NET app so that it can function offline. My server database is SQL Server 2005, and it's copying to SQL Server 2008 Express.
It doesn't have to be anything fancy - just start from scratch (or delete the existing db), copy all tables/constraints/foreign keys, and copy data from some of the tables. I don't mind keeping a "schema version" in my database so that the app knows when its existing schema is outdated.
I've been looking into the Microsoft Sync Framework, and it appears that I have to make a SyncTable for each table in my database, and frankly, that seems like too much work and maintenance. This is the code that I'm finding in examples:
SyncTable orderDetailSyncTable = new SyncTable("OrderDetail");
orderDetailSyncTable.CreationOption = TableCreationOption.DropExistingOrCreateNewTable;
orderDetailSyncTable.SyncDirection = SyncDirection.Snapshot;
orderDetailSyncTable.SyncGroup = orderSyncGroup;
this.Configuration.SyncTables.Add(orderDetailSyncTable);
I suppose I could list all the tables in my database and enumerate over them, but it just seems like there should be a better way. Am I missing something in the Sync Framework, or is there something else that would accomplish this sort of thing?

I gave up on Sync Framework; using SQL Server Management Objects to accomplish this instead.
http://msdn.microsoft.com/en-us/library/ms162169.aspx

Alternative to SQL Server for a simple web app

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.