We Keep Coding

Publish C# Desktop Application with SQL Server database

I have a Visual Studio project that has different Windows Forms and a SQL Server database attached. I want to install this project on my client computer (others). As I haven't published any project before, can someone guide me in an easy way.
When I tried to publish (installed) this project in my computer (setup file would be created and the application would be installed but) but I get the error shown below while saving update delete data. Please guide me correctly.

You are taking a completely wrong approach here.
Databases are not meant to be installed in client's computer. If you have a client/server app, the database should be located only in your server, and the client will access it/request to write into it by sending requests over a protocol like TCP, which your server will react to.
When you add a database to an app, you provide a connection string and this connection string is related to YOUR instance of the database. If you wanted every client to use a unique DB, you'd need to go over to their computers, install a DBMS, create the database there, then edit the program code to include the connection string for the specific client instance. Obviously this is not a viable option unless the clients you're talking about are just like your immediate family/roommates.
If you intend to provide your clients app with saving/reading data functionality, you'd need to implement it by having the data written into a local file which the program will be able to read from, such as a csv or a tab delimited file. Not through a database. At least not SQL server. If you're completely obligated to use a DB, then think about an embedded, serverless DB like one from SQLite
The reason you're getting that error is because the client's program is trying to look for the database instance that is indicated in the code, but of course, this instance does not exist in the client's computer, so the client cannot reach it to do anything.
Also, please remember to use exception handling. We cannot tell what the exact error was (although it is obvious) because your code is only saying "an unhandled exception happened". Always wrap your code In try/catch blocks and at the very least have them print the exception to a console so that you can know WHY did a program failed on runtime.

Making database mdf work across different computers

I know this is kind of a stupid question but it gives me a lot of problems. Me and my partners in college projects have a lot of issues making the database mdf work when we send each other the visual studio projects. It gives us errors about the versions of sql server. Is the only solution to this to install same version of sql servers for the entire team or is there some other workaround?

Yes, you must be using the same version of SQL Server across all PC's.
You can never "go back" in time with a SQL Server database - once a .mdf file has been attached to a given version, it can never be attached to an older version anymore. And you cannot get around this by using the database compatibility level, either - the internal database file structures are just too different between versions, and no backwards "downgrade" path is provided.
One way to get around this would be to have a common, shared server somewhere that everyone can connect to and everyone can work with - making in unnecessary to send around "free-floating" .mdf files altogether... after all, it's SQL Server - a server-based system - not so much a file-based "database" system ....
Another way to go would be to stop sharing the binary .mdf file, but instead work with SQL scripts that you can exchange within your team, and that each team member can execute locally on their respective SQL Server instances - regardless of their local version

I suggest that instead of passing around mdf files, every person on your team creates the DB and then uses SQL scripts to create the objects. These scripts can be very easily created and exported from the SQL Server Management Studio.
This has the added bonus of being able to put the scripts under version control as part of the project.

I made such practice, with one way , by create separate pc running under windows server, only using as sql server to store all data record , then the data is called via "connectionStrings" of IP with server name of user policy, which is also secured by password and username , so this practice is used , to enabled two different programs to share that data , for example , that I made ( one web localhost app to create internal registration ),( the other web app using to access to mainpage via Login form).

Solution for a no-server multi-user application/database?

I am at a dead end an I could really use some help.
I intern for a huge company. My projects involves creating an application to automate/simplify the work of a retiring employee.
The problem here lies in the strict company policies. I am a developer stuck at business end of the company. Therefor IT gives me nothing:
I don't have a server (nor web nor database)
I can't create a server, because no pc will be running and we can't keep them logged in due to single sign on with company cards.
I can't install anything on the pc's in the network.
I can access a share file server, that is backed up every day.
The libraries involved have to be free
A central database has to be accessed by a dozen of users (at once)
The database will recieve new data every day and will grow accordingly
The users will both read and write from/to the database
Preferably C#.NET or WPF solution
Application needs to open files stored on the shared drive. ( Only once, the important information will be extracted and stored in the database.. the file will then be removed)
My initial idea was to use silverlight (which runs standalone) in combination with SQLite. I ran a test and Silverlight files stored on the shared drive work. (Silverlight is installed on every pc on the network) This is my preferred front end. However (correct me if i'm wrong) I tried SQLite-net and I needed to add the sqlite3.dll to my windows/system32 folder, but on the network PC's I don't have access to the Windows folder, so this can not be done.
Also I read that SQLite or files in general can become corrupt when accessed by multiple users as one, so maybe I thought locking was an idea.
Which solutions are there to my problem?

I worked for a company for several years writing software for police departments to manage traffic collision reports. Police stations usually have little-to-no IT support, so we faced many similar limitations. The company actually did pretty well using Microsoft Access databases, with the setup looking something like this:
The shared drive had an Access database file (.mdb or .accdb) which was the actual "database".
Client computers (at the officers' desks) had Access applications with local "utility" tables for temporary storage, UI defined in Forms, and logic defined in Modules. Each of the client machines were connected to the repository on the shared drive by using linked tables. Local client configuration was stored either in the Access application in a config table, or in a text file on the machine.
It's not the cleanest solution, but it would allow you to create and maintain a unified solution using files that don't need to be installed and don't require any funny permissions, as long as everyone has read/write access to the shared drive.

Create a website. Today you can host ASP web apps in a stand alone .exe. By doing so you can make sure that the shared files are only accessed by one process. You can also limit the access to sqlite.
It also means that you do not have to distribute anything. Simply start your application and tell your users which url and port they have to browse too.
As for permissions, only the account running your webhost requires access to shared files etc.

You should take a look at ScimoreDB. It's an embedded database that supports multi-process read/write access. If needed it can also act as a client/server database; even as a distributed database with multiple nodes.
It's free to use and deploy. It has support for C++ and .NET. Only disadvantage is that it only works on Windows.

Creating a Database Project without Local SQL installed

I might be completely off on this, but is there a way to have a database project point to a remote server? My reason for asking is that we have a shared DEV Database for development use, and it seems like overkill for each developer to have a local instance of SQL Server as well. Is there a connection string that I can set or modify to point the remote server, or is the only way you can have a database project is to have a local instance on your machine. Please let me know if what I am asking does not make sense.
Thanks!

SQL Server Data Tools (which is what you're using for your database project) can work in two ways:
Connected Database mode.
Project oriented, offline database mode.
If you look at those articles. you will see that for development purposes, in both cases a localdb instance is needed. The local server is a limited SQL Server Express installation, which comes by default with Data Tools. So all you need to do is install Data Tools. If you already did, then you have localdb support.
More on this from MSDN:
Microsoft SQL Server 2012 provides a local on-demand server instance,
called SQL Server Express Local Database Runtime, which is activated
when you debug a SQL Server Database project. This local server
instance can be used as a sandbox for building, testing and debugging
your project. It is independent of any of your installed SQL Server
instances, and is not accessible outside SQL Server Data Tools (SSDT).
The workflow, for a central development database, would be:
Create the database project and distribute it to each developer.
Developers work "offline" and add/remove objects from the database.
Before submitting the changes to source control, each developer also syncs the local database changes with the central development database.
The rest of the team gets the changes from source control, so no manual sync needed. Only a new localdb publish would be required.
Of course, there are many other things to consider: local data (see here about replicating data to the real database), and some features not supported by localdb (like full text search).
I've tried this flow and works really well if you learn to control it. You always get a consistent central development database, without intermediary and unstable modifications.

You can change the "Debug" properties to point to a different server than the (localdb) instance. Most times you won't do this unless you're using some features that aren't supported in the (localdb). That would let you push the changes to your central server on each debug build. However, this could have a lot of unintended consequences if you're just playing around. The better option would be to leave the (localdb) debug instance alone and set up Publish Profiles for a real "Local" SQL Server install and for your shared Dev server. That way you can do all of your dev work offline and only push changes to the shared dev server when you're ready to do so.
I have a series of blog articles on SSDT at my blog that may be helpful: http://schottsql.blogspot.com. I'd also recommend looking at Jamie Thomson's blog at http://sqlblog.com - he has a lot of tips on DB and SQL Projects that could be helpful.

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.