We Keep Coding

Best choice of database for my C# application

I'm writing an application which will involve interaction with the database. The application will be used by users from the scale of 100 to 1000 and the database should be able to store up to 100,000 rows of data.
Previously I have used Microsoft Access but my users were required to install microsoft access database engine for my application to function as intended. I want my application to as light weight/portable as possible, so is there any better alternatives where users will not be required to install any third party components to run my application?

Look at mongoDB, it is an open source non relational database that has picked up popularity. Its is very fast too.

Depends on whether the DB will be server side or client side.
If it's server side it's up to you really, I would personally go SQL Server as I know that best, or even a mySql/phpMyAdmin combo. But if it's to reside on the client machine try SQLite (just a warning though it is exactly as the name suggests, LITE, so a lot of the more complex SQL might not be supported). SQLite may be exactly what you're looking for depending on the complexity involved in your project.
ALSO: SQLite is supported on iPhone, Blackberry and Android as well. So if you wanna go mobile, no problem.

Your application could connect to a cloud database (like SQL Azure). That will not require any third party components and it will be accessible from anywhere/any device.

Do you need a only one database for all the users or every user has it's own database? If it will be on the server side, i would prefer SQL Servers (ex. MSSQL, MySQL). But for clients side, SQLLite would do the work.

You should consider if a SaaS model is relevant, in other words if you could benefit from hosting all your users' databases on the cloud and let clients access it by remote. In your scenario I would consider a SaaS model if: (1) your users need to scale up their individual database beyond the capacity of their local machine, (2) there is a need to share data between the databases of different users - or maybe this could enable good features you don't have in your system today, or (3) users find it a drag to have to run the database on their local machine, because of the resources it uses up, uptime needed, backups, etc. If any of these are sometimes true, hosting all the databases on the cloud with some sort of multi-tenancy arrangement might be a good solution and will make your application as lightweight as possible because you don't need to include a database at all.

.net queue system

I am building a system which is made up of 2 application
ASP.Net Website where jobs will be created for engineers to visit data held in central database
Windows Forms Application running on Laptop where jobs will be synced from central database then a form is completed and data sent back to the central database.
What will be the best way to transfer the data, the laptops will be remote and may be on a slow connection.
I will be using SQL Server 2008, Entity Framework, .Net 4
I have looked at the Microsoft Sync Framework but unsure if this will do whats required, also thought about having a web service where the windows form client can pull and push data to.
I have had bad experiences with MSMQ so what to avoid this.
How would you approach this?

Take a look at merge replication for SQL Server. This would allow your laptop users to make changes to the data they've received while offline and later sync back to the central database.

I believe MS Sync framework is designed to handle just this problem. While you can use MSMQ, you'd be writing most of the logic to do the syncing yourself. Sync framework should give you a better abstraction and take care of most of the details.

From simple desktop application to client server application

I have developed a simple desktop application with a SQL Server database for a single PC and now the client want to make it work on multiple PCs. I want to know what is better: for the moment I have remote the database from sql management and all application just connect to it. Is this a good idea or do I have to do some modification to improve the executing of the application?
The database has a lot of information to be imported to the application.
I don’t have a good idea about WCF but would it help to read about it?

You could have a dedicated server with database hosted on it and all the client applications could connect to it. But one thing you have to take care of is transaction management that is while a user is updating some piece of information, no other user could change that piece of data to make that data inconsistent. You could a look at this post describiing Sql Server Transactions.

Depending on the requirements I'd recommend keeping the local database as cache for speedy application start and implement a synchronisation process where the local and remote databases are compared from time to time or triggered manually by the user.
This would be very similar to how for example IMAP email clients or Evernote works.

How to handle intranet application to work offline

I developed a small expense report system used to replace an excel file that was very old.
The setup was pretty simple:
-UI is jquery, asp.net, simple css
-Back end is sql server 2005
-There are some additional tiers for the business layer.
Typical tiered application. It's running on IIS 6 as an Intranet site. It's a lot simpler to use then the excel sheet but of course there is the guy who doesn't seem to have an internet connection so how can he submit his expense report?
I thought of an offline system that serializes objects but this again seems to be a bit complex as eventually these serialized objects need to get back to the database layer. I'm thinking more on the lines of just telling them to submit an excel spreadsheet to an "admin" who does have an internet connection and have them put in his / her expense report. But I fear the "admins" will hate this.
Even if I whip up a desktop client application, I'd still have to hit the network to get to the data layer.
Any other ideas of how to handle the guy who cannot VPN or get on the network but once loved his excel application that I havent thought of?

We implemented a few solutions where the users don't have a connection. One was a WinForms app, and others were ASP.NET apps. For the ASP.NET apps, we modified them to run using IIS on the laptop or client PC, since you can install IIS on a client OS.
What we ended up using as a pattern was to use a DataSet locally to hold/parse.manipulate data on the client PC, and then serialize it to an XML using the built in DataSet.WriteXml method. Then we created an "Upload" screen (asp.net page or WinForms page) that shows the pending uploads. This uploads the DataSet to an ASP.NET Web Service. Since the DataSet object is serializable, using it in a web service is the least amount of work. The web service handles actually inserting/updating the database.
It is actually a lot less work than it sounds like, and the pattern has been so successful for us that it's become our standard method for handling disconnected apps. The troubleshooting on these apps has been negligible, which to me speaks volumes for the simplicity and reliability, compared to other approaches we've tried.

You can implement SQL Server Merge replication. There was a little bit of a learning curve, but I figured it out and implemented it in a couple of weeks so its definitely "do-able". You can have a desktop app that updates a sql server express db and then synchronizes the changes using replication at your choosing (maybe when the user is connected to the network).
How Merge Replciation Works
http://msdn.microsoft.com/en-us/library/ms151329.aspx

You can do a variation of the email xls file to admin. Instead of the admin re-inputting the data, you could have them upload the xls file and your system could parse it and enter the data. Works quite well especially if the xls format is unified.

Using the Office toolkit and macros build into the users Excel application the functionality to export the data into an XML dataset and transmit them when the opportunity permits. On the server end build an adapter that reads those XML files as they arrive and inserts the appropriate records as required.

Shaky connectivity - favor web or desktop app?

I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.

You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.

Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.

If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.

You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages

You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.