So, after tinkering with programming for about 3 months now, I find myself in a situation where I'd like to try to develop a database windows application that can be used by a few users on my office network.
What I'm trying to do is create a simple property database for my small company that can be accessed by the half of a dozen co-workers.
The issue I'm coming to head with, is that I'm not really sure if I'm creating my windows application the correct way in order to share a single database on a server on our network. I have created, what I believe to be, a single user application with an express 2008 DB. However, I am not sure if I can take this program and migrate it to a multi-user program.
I've been trying to search for a quick guide with maybe some hints and tips of how to initially setup the project to correctly deploy the project as a multi-user application. However, I've been unable to find anything of relevance.
I really have no problem re-creating the project from start to finish, as it's good practice and I'm sure I have inefficient code in many places. I just need somewhere to start.
All of our machines are using WinXP and I'm pretty sure we have SBS 08.
Noob appreciation would be granted to those who help and thanks for your time.
Edit: I'm using Linq-to-Entities, if that means anything.
most likely you will have a local DB with your application. To make it a multi-Client one, you need to host the DB at a central place. Now you need to supply all clients with the correct connection string to access your DB.
Check the syntax for the connection string here: http://www.connectionstrings.com/
If you did everything right, that should be it (well... Excluding blocking issues, concurrency, update methods and validation ect... Who will win if 2 guys work on the same record...)
But those questions would require a whole new chapter ;)
The way to do is keep your application the way it is and put the database in a central place.
Then set the connection string correctly to point the app to the central database.
Like this: Suppose you have installed sql server on a machine named mypc then the connection string will be like: "data source = mypc ; initial catalog = mydb ; integrated security = true"
what that means is,
The database named mydb resides on a server called mypc. So that your app can access it. You do not need to worry about anything else. SQL server will handle other things for you. Also you can use sql express for this too. Just modyfy the conn string to
"data source = mypc\sqlexpress ; initial catalog = mydb ; integrated security = true"
If your application Requirement is multi user and within a single office (Same place) with having LAN Connection then the you can go for the windows application and the same application deployee on the multiple system in the office and set the single database for the all application so that you can use the application on multiple machines with a single database.
In this way you dont need any changes in your application just you need to modify a single line of code in the app.config if u wish to change the application.
Related
I'm very new to App deployment. This is my first one actually.
I developed an app which uses a SQL Server database to store its data. I created the SQL Server database with a script. However, neither the script nor the DB itself are part of the "package" of the app. I simply installed SQL Server Management Studio with the default settings, created a new file starting with
USE [Master]
GO
CREATE DATABASE [Database]
and filled up all the details.
The app works in my machine of course, but when I Published the app and got the .Exe, it doesn't work in any other computer, of course because it's not creating a Database to go with it, and the connection string that it uses for the queries is the one that I gave it from my SQL Server instance.
So, I want to know how to actually include the database (or a way to create it) in the "installation package", and also for the program to dynamically get the necessary connection String to operate on any computer where its installed. Right now, I AM fetching the connection string from App.Config with the ConfigurationManager, but of course, the Connection String in App.config is the one that got added when I added MY instance to the project.
Any sort of guidance would be appreciated. I searched related questions but the only ones relevant had some deprecated methods. It's still not very clear to me how it would get the connection string dynamically if its not going to be the same instance.
On a semi-related matter...I noticed that my app was being executed with just double clicking on "setup.exe". Setup seems to imply that it will only install it and add an executable...it's kind of misleading to execute the app itself from the setup, isn't there another way to change that?
I'm writing a database application in C#.
I need to place the db connection in one location and call it once I need in several windows forms. I'd be thankful , if you can help me.
A common way to do this task is to store the connection string in the app.config (web.config in a web application), either as a connection string or an application setting
Have a look at: System.Configuration.ConfigurationManager
or this article
"several windows forms" -> However it sounds like you want to share the same connection string between different applications, perhaps on different machines so you have only one place to modify such data.
You will then need some kind of central repository or configuration server to do this task... for example, a web service that supplies the connection string to the various applications.
You would need to lock down the network for such a configuration server so that it is not exposed to dodgy people both on the internet or internally in your organisation.
You would need to cache to connection string per application somewhere after the application loads (static class, singleton.. etc..) so that the central configuration does not become a single point of failure.. if the configuration server goes down you will still want to connect to the last known good config.. also you would not want to constantly query for the connection string because it would be way slow.
This might be overkill for what you need, it might be as simple as reading a common file off disk or deploying the same .config to each application
There are many ways to solve this problem, choose the simplest one with the least moving parts.
You can use Application Settings in Windows Forms to store connection string.
For details you can see this walk through.
How to: Create Application Settings Using the Designer
i would like to Deploy my windows application written with c# (Express edition 2010) and SQL server express edition 2008 and i want to know how to do the following:
The steps to deploy the Application and how to set all settings(i think with express edition there is only one way click once method, but how set the settings for it?
after Deploy my application what i have to do to setup or install it in the customer machine(requirements for software side) to make it work?
What is the best location to place my database files(MDF and LOg) in the customer machine c: or D: and how to prevent any one to access the database without using Application because the connection string is like that:
"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\FamilyHistory.mdf;Integrated Security=True;User Instance=True"
Finally i want to know how to make backup for the database from time to time , is there any automatic method to do that or i have to make manualy by copy it form the customer machine.
You can have a look at a number of deployment methods. You can use click once but i strongly advise using something like NSIS(open source). You can use a software HM NIS Edit(also free) that does the hard work for a .net project. Try it on your own machine and then you will know how to deploy. By client i take it you mean your customer rather than client/server type client?
the answer to three i believe (although i rarely do the old file sharing nowadays) that you should place the file in the temp folder in windows, however, i am willing to be wrong about that.
It depends on what data provider you are using however, you simply create a sqlcommand object(as i'm sure you know how) then enter in the backup sql something like:
BACKUP DATABASE AdventureWorks2008R2
TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
WITH FORMAT;
GO
i hope that has helped.
Right now I have a Winform app with a SQL Server back end. The DAL is comprised of Linq to SQL. One of the complexities of this app is it's need to function offline.
I have accomplished this by using Merge Replication to keep there local SQL Express instances in sync with a central SQL Server. I have some logic that detects there connection state and switches the contexts connection string appropriately.
My question is thus, will this also work with Silverlight 4? In theory, I would detect when they are offline and switch the connection appropriately. Thoughts?
EDIT
It seems this is, in fact, possible. See HERE.
What I NOW would like to understand is if I could make EF or L2S work with this instead of RecordSets like it shows.
With Silverlight (any version) the problem isn't so much connectivity to the database. In Silverlight, you don't have it. The only thing you can do is make a call back to the server that the request originated from.
Because of this, you would have to have some sort of local IIS instance running and connect to that, which would then in turn connect to the local SQL instance.
The thing is, if your SL application was loaded from your site, and then connectivity was lost, your app couldn't detect it. You would have to go to a new link to the server on the local machine and then have them switch back when they have connectivity again.
For something like this, it's probably best that you stick with the Winforms app and determine whether or not you have connectivity there. That way, you can switch which database you hit when you don't have connectivity.
What casperOne is saying is that out of browser Silverlight does not have access to a full fledged database on the client. The best that can be done is to use some sort of compact database either in the isolated storage or within one of the few accessible folders with Silverlight 4. I have personally used siaqodb.com , but you will have to keep the data synchronized manually (which can be a nightmare).
More recently I have seen someone get access to a SQL compact database. However, there could be more ways of accessing data now. It has been some time since I've looked for a client side database for Silverlight.
How can I make a program use a SQL Server database, and have that program work on whatever computer it's installed on.
If you've been following my string of questions today, you'd know that I'm making an open source and free Help Desk suite for small and medium businesses.
The client application.
The client application is a Windows Forms app. On installation and first launch on every client machine, it'll ask for the address of the main Help Desk server.
The server.
Here I plan to handle all incoming help requests, show them to the IT guys, and provide WCF services for the Client application to consume.
My dilemma lies in that, I know how to make the program run on my local machine; but I'm really stumped on how to make this work for everyone who wants to download and install the server bit on their Windows Server.
Would I have to make an SQL Script and have it run on the MS SQL server when a user wants to install the 'server' application?
Many thanks to all for your valuable time and effort to teach me. It's really really appreciated. :)
Edit:
To clarify, each business will have their server completely separate from me. I will have no access whatsoever to them nor will they be in any way connected to me. (I don't know why I should clarify this :P )
So, assuming the have ABSOLUTELY NO DATABASE SERVER installed; what can I do?
Ok, part of the answer, dealing with the SQL Server Database (and frankly SQL Server Express will take you a long way - 4Gb of data) and the server install elements.
Firstly make installation of the SQL an SEP, make it a pre-requisite possibly tweak your installers to test (challenging) but substantially point them at the links to SQL Server express and let them get on with it).
Secondly separate installers, as suggested, for your client and your server elements.
Finally, how to build the database - I'd suggest using code to create and maintain (update) the schema i.e. once you have a connection to a server you can run code that calls DDL that does what is necessary (something like suggested here: How to create "embedded" SQL 2008 database file if it doesn't exist?)
A question - are you intending all communications from the clients to go through you WCF service?
Your install application should:
Obtain a SQL Server name, a username (with apprpriate rights to create a database) and password.
Either run SQL scripts using the locally installed command line tool or from code using SMO (for instance), against the user supplied server with the supplied credentials.
BTW, Before you expend effort writing an open-source help desk, have you checked what is already available? Also, Open Source Helpdesk
It is not so straightforward to deploy a client/server solution with an automatic installation.
You probably would then be better off to deploy your server installation together with a database engine and a skeleton database already setup according to your wishes. This is to avoid tampering too much with the existing server - who knows whats on it.
Also you say you want to install WCF services, well this would probably mean installing them on a customer server, in theory this shouldn't be a problem however in reality it could be, depending on what is previously on the server.
Do you want a single SQL Server instance running on your machine, or one on each of your customers' servers? If it's the latter, you'll want to install a SQL Server instance - anything from the (free, but limited and not open-source) SQL Server Express to a more expensive SKU - on each server. You can include this step in your server installation package; MSI installs make it very easy to bundle a MSSQL install.
Then you'll need to drop a schema, and maybe data, on the instance. You could do this as a step in your installer, or as part of your application setup process. It possible that a SQL Server instance, or more than one, might already be installed on the server, and your post-install step should allow the user to specify which instance on which to install your pieces.
Then, include a database configuration piece in your client application. Ask the user - or take from a configuration file at client install time, to allow for unattended or unprompted client installs - server connection details, like server name and authentication information.
A word on authentication - since you appear to be building Windows-based tools, use Windows integrated (domain-managed) authentication if at all possible. Don't get in the business of storing logins, but instead rely on the existing domain to manage logins. A good strategy is to use active directory groups to manage access. Grant access to a particular group in SQL Server, and defer group membership to Active Directory itself. If you can't gain the access necessary to do this, then grant permissions to AD user accounts themselves. Avoid creating SQL Server logins, the use of which open the door to some possible security problems.
I understand what you are trying to do. If I were you, I'd do the following:
Provide 2 downloads - 1 for client and 1 for server.
Forget about MS SQL Server and perhaps go with MySQL, since it really is open source. You could probably get away with using MS SQL Server Express Edition, but if your data set gets gigantic large (which is common with help desk databases), you'd be stuck.
As other people pointed out, on very first run (or at setup time), I'd have the client app locate the server.