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).
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 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.
I have an application written in c# [WPF] which involves lot of communication with several databases, hence i used SQL server 2008. Now i need to move the code files along with the database files to another system(it doesn't have sql server installed). Once i run the applications exe , it gets struck as it is not able to retrieve data from .mdf file.
Is it possible to access sql server 2008 installed in my system through a network ?
It is pretty simple . I think you are using .mdf files as your database. Instead of it use .sdf as the database format which is mostly used in mobile development. There are lots of .mdf to .sdf converter available in the net.
You can have the second system access the SQL Server of the first system.
You need to modify the connection string so that it accesses a server on a remote machine, and make sure the proper authentication mechanism is used. If both machines are on the same Winodws domain, it's going to be fairly simple.
I have a nice program idea, it will be a very simple application that will save your username and password on a sql server database file, i know how to do it, but the problem is i don't want the client to install sql server in order to add or remove a record in database, besides i want my database file embedded into the application so the user have a single .exe file, i heard about a library called sqllite or something, it`s function is not to let the user install sqlserver to make the application work.
You can use SQLCE and search for SQLCE private deployment, basically it is a light weight of MS SQL on client side. With privatedeployment you just need to copy related DLLs to your project folder without installation.
You are looking for SQL Server Compact edition.
You need to use a file based SQL database.
There are several - most popular are:
SQLite
SQL Server CE
See this SO question - Free portable database.
As you mention, Sqlite is an option. It's a compact and file based database. No need for installing anything. The full database resides in a file. You'll need to reference the Sqlite database engine for connecting to it, however.
I probably wouldn't use SQL at all if you are only going to create one table with a few (< 100) rows. Its way to much overhead for that small amount of information.
I would save the username and password in a file, then use the Enterprise Libraries Cryptography Application Block to secure the file.
You also most likely don't want the storage engine embedded into the exe, then your passwords are tied to that specific application on that specific computer. You will have to implement an import/export program anyway to move your info to another machine.
Check out http://keepass.info/
Yes , you can implement it by
SQLite ,
SQL Server CE ,
Or Xml
And also , in my last project , the application call the webservice when need to access DataBase.
So , there are lots of ways to avoid install SQL Server on client PC .
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.