I have a WPF project set up to use a local SQL Server Compact database through an ADO.NET Entity Data Model in Visual Studio Express 2012 for Desktop. The project works great, on first run I can load all of the data, manipulate it as I please and come back later with the changed data still in place.
I noticed while doing a little restructuring to the schema that the data visible to VS was only the very first bits of data that I entered manually when creating the database and the next time I compiled all of the data I had added since was gone!
After some digging, I came to the conclusion that the compiled version of the app was using the SDF file sent to the bin/Debug folder by the file's Content:Copy If Newer build action. This means that there could be as many as 4 different copies of the database to be worried about: project folder, debug folder, release folder, and the deployed copy on the end user's PC.
I would like to have a single copy of the database on my dev machine that is accessed by both debug and release compiled versions and the database explorer in VS that is installed on the end user's PC by ClickOnce. I suppose I could change the connection string to an absolute path during development and hope I can remember to change it back to relative before I publish for deployment.
Finally, I foresee the need to release updates for this application as well and am worried that such an update would erase the end user's data if improperly done. If possible, I would like to be able to only update the schema of the end user's database without touching the data itself whenever I release an update. If this is not possible that is acceptable and I'll just have to make sure I put every structure I can think of into the database before my first deploy.
In summary my questions are the following:
How to share a single sql compact database between VS, debug, and release?
How to handle local database during application deployment and updates, with the optional ability to update the database schema without erasing the data?
I have a similar application and I keep the database file completely separate. Because you may also need to do updates that you don't want the user database overwritten. I have a process that checks the database schema before the EF connection takes place. So when my users install this application it requires they download the database file from my webserver and puts it in a specific location on their computer.
Related
I am trying to make an application for managing a small store, which will be offline. I am considering using SQLite for my data handling needs. Once I create the installer for this project, does the database get attached to the installer or will have have to take additional steps to make the application work.
Also is SQLite the best way to approach this or should I consider something else?
Since SQLite needs a file to work with you can include a file which contains empty schema of your SQLite database in your setup project and copy it to working directory. Or add your empty db file as a resource to your application. And in your connection string builder/provider check existence of the file if it doesn't exists read it from resource and copy to the target location. And also SQLite is good option for that kind of usage.
I have code that generates SQL scripts that will run nightly. I want to check this into source control each night, so I get a history of changes to tables etc. as well as picking up new tables and when tables are deleted.
I have a team project created in Visual Studio Online.
From looking online it looks like there's no reliable way of automatically picking up changes locally and committing them to VSO. I'd have to create something that compares what I have locally to what is in VSO, which to me seems error-prone.
If I use the command line utility it looks like I have to tell it what is added and deleted (i can't just check everything out, then add/edit/delete my local files, then commit).
I've also looked into the Team Foundation Server class, but that's obsolete.
TL;DR: Is there anything I can to do easily sync local changes (add/edit/delete) to VSO, without having to tell it what's been changed?
Why not just check in the changed from your workspace?
If you have a Local Workspace that includes the folder that you generate the SQL into you can just call tf.exe checkin to get all of the changed into TFS.
+Daniel is right.
Let's assume I'm going to create project in ASP.NET MVC 4 and users should be able to easily switch between test/demo database and production one. Both databases will have same schema, but different users and data.
Should I simply use two versions of web.config with different connection string and deploy it to two separate IIS instances?
I thought also about choosing database from dropdown list during logging in, so I would need only one IIS instance and one config with two connection strings. Do I gain anything from latter approach other than more complex code to handle it?
In our system we use web.config transforms and use MSDeploy with Publish Profiles in the project for our two different servers, Dev and Production.
To deploy to Dev, you simply click publish and select the "Dev Server" Publish profile and out it goes. Same thing on production, but you select "Production Server" from the publish profiles.
Dev and Production are two different physical servers, which is ideal. What if you do something where you need to reboot the dev server to test some big changes, or some new updates etc, you don't want production going down with it.
Our environment is virtualized so it was easy to create a production server and a dev server. Really we created a dev server and once done, we based production off a snapshot of the dev server, so they are basically identical with different code bases.
We also setup Visual Studio Remote Debugger on both servers so we can debug code without having to install visual studio on them.
Being on two different servers, they have different urls, e.g.
something.com
login.something.com
admin.something.com
dev.something.com
dev.login.something.com
dev.admin.something.com
Now, we also use twitter boot strap and out design has 2 columns on the left and 2 columns on the right for spacing. So when on the dev server, I render giant "DEV" images vertically in the column spaces.
I should also mention source control. We use SubVersion for a source control server and Tortoise SVN with the Visual SVN VisualStudio extension to keep our projects in source control.
It's setup to the point that any developer given access to the code can to a Get on the repository and open it in visual studio 2013 and click publish. The code is very easy to move from developer to developer.
We also have some versioned assets the site uses and we have the dev/prod servers setup with Tortoise SVN as well. E.g. EmployeePhotos are in source control, and a developer can add new photos to SVN and go on the server and go a get on the virtual directory containing them and they are uptodate. Handles deletes as well. If we delete a folder from source control and do an Update on it, SVN deletes the deleted images.
All code aside, I would host the two separately. The chance of someone screwing up production data when they think they're messing with test data is high enough that it's better to have explicitly different URLs. I'd even probably have visual cues in your Master layout (color differences, differences in the main page header,etc) to make it clear to the user where they are and what they're expected to do there.
Even if you're not worried about that per se, you're right that managing it internally will be more complex as well, and error-prone. I'd steer clear of it.
I am using SQL server 2008 R2 and VS2010. I made simple application by using this tools. I attach database as .mdf in my application and deploy that application on other machine its works fine. Now if I plan for new release of my app which some extended features, I can upload Code by DLL, But problem is updating .mdf file, to handle this I am exporting database into .xls sheets (Application have one utility to backup database) and then import into SQL Server to create new .mdf file. Someone have better solution on this? Can I open old version of .mdf file in SQL Server(Third party software) and Execute DML/DDL script on it to make latest code and database compatible ? May I keep .sql file in one of my project code and execute it by some utility..? Any Class in C# which can handle this..?
I did not get your query completely. Do you want to upgrade the DB through the application?
You can of course run .sql files through your application, but I'm not sure it would help you change the Database configuration.
Alternatively, if you already have the updated .mdf file and the database name is same, then you can follow the following steps.
1. Detach the database by SSMS in the third party environment through SSMS.
2. Replace the .mdf, .ldf and .ndf (if any) in the disk.
3. Attach the updated .mdf file.
This will get the new Object definitions as well as data.
As far as I'm aware, there is no process for merging .mdf files, because the SQL Server might not be able to identify the similar objects properly as sys tables may be different, and also would not know which data to keep in the final data base, in case the table structure, constraints or data conflicts occur.
However, looking at your requirement, the best way I can suggest is,
1. Generate the Alter scripts for the tables modified (By right clicking on the object name and using Script Table As.. option). Of course, I assume you have the list of objects modified and the modifications.
2. Connect the two DB servers over network and write an SSIS package or Import data from the old DB to the new one for the tables you want.
Hope this helps.
For example I have developed c# application (with sql database) and installed on win OS, then use to save some data. Now I need to install new window, what did happen with my saved data?
Generally the data you are referring to might be either created during the installation or when the program itself is used (like an OLTP applicaiton). If lets say you have followed all the best practices and created the application using the created installation package, then the uninstaller should give you the option to either store your preferences like template and layout and such(if your program supprts those kind of things). But as for the data and even more in your case data stored in SQL is not deleted UNLESS you specifically mention in the uninstallation to drop the table or database. So as you are mentioning new window, just ensure the database exists and all the data is in contact(most likely it will be). Then also ensure that the new window is pointing to the data with all the necessary constrings and authentication.