I would like to use the EntityFramework model to connect to an embedded SQLite database in my C# application. Everything works fine but as this is the first version of the software I expect future changes to have a cause changes to the structure of the database.
I am concerned since I do not know when a user would upgrade from ver.1 to say ver 2. how to alter the strucure of the embedded database and of course save the existing data.
Anybody else run into this issue, and how did you solve it ?
Thanks
I wrote a complete upgrade framework in C# to handle this type of problem. It served me well in a big client project and saved me tons of work in the process.
You can read about it Here. It is in the public domain so you can use it for your projects (including commercial projects) without paying anything :-)
If you have any specific questions I'll be happy to help.
I got an idea but an unsure if it is a correct approach:
write an small external tool to alter(upgrade) the database structure, and run this in the application installer.
What do you think about such an approach ?
Related
I realize this might be a stupid question, but my GoogleFu seems to be letting me down here.
I'm writing a very simple little app for myself, but I want to be able to store some data to a db file. Currently I'm using SQLite and although it works I would like something even simpler if possible which does not require me to create tables and columns before hand. Also, for some reason the SQLite takes it's sweet time when making the first connection on app startup. I've not been able to figure out why and it's becoming somewhat tiresome to have to wait 30-60sec for the first connection and that's with it on an SSD. After that first connection it's perfectly fine and responsive. But I'm getting off topic...
I found db4o and that seemed like it was what I wanted, but it seems that project is dead. I just want the simplest and most basic option that will give me some database like capabilities where I can Insert, Update, and Delete records.
Any suggestions?
Honestly, the best suggestion I could make is to figure out the latency issue you're having with SQLite and continue using it. There are other options to be sure, but SQLite is a very elegant solution to local data storage.
That said, if you're insisting on something different but don't want flat-file, I guess you could try xBase
Thanks for the responses. I ended up just serializing my C# object to XML and dumping that to a text file every time a change is made to the object. Then at app startup I just read the text and deserialize the XML back into an object.
This way I can add or change the object's definition with ease while I develop the application and don't need to create or update any tables or columns like I had to with a SQLite DB. I also don't have any dependencies other than .net 4.0.
If I was going to store something like Client Info on a crappy desktop application then I would use SQLite as the data would have some importance.
I'm just storing a list of url's (Along with some other data) that can easily be replaced if the data were to be lost.
I do mostly front end dev work and some MS SQL. As such my knowledge with database tech in general kinda sucks, so I've learned about some other DB tech.
Thanks Again
I have two sql servers installed on my computer (SQL2008 EXPRESS) and also SQL2008 that comes with the specific software that we are using.
I need to make a service that runs all the time and at a specific time updates the non existing records in the SQL2008 EXPRESS from SQL2008.. can you suggest a way of doing this?
Currently the best thing I got is making a local copy in excel file, but that will result 365 excel files per year which I dont think is a good idea :)
p.s. sorry if my english is bad :)
You don't have to hand-craft your own software for that. There are 3rd party tools like OpenDbDiff or RedGate dbdiff to do that. These tools generate the differential sql that you can apply on your target database.
I'm confused when you mention Excel. What would Excel have anything to do with moving data from one SQL database to another?
The short answer is, if you need a C# service, then write a C# service that copies the data directly from one database to the other. The problem that you are trying to solve is not very clear.
Having said all that, and with my limited understanding of the problem, it sounds like what you need is a SQL job that is scheduled to run once a day that copies the data from one server to the other. Since it sounds like they are on separate instances, you'll just need to set up a linked server on either the source or destination database and either push or pull the data into the correct table(s).
EDIT:
Ok, so if a windows service is a requirement, that is perfectly acceptable. But, like I mentioned, you should forget about Excel. You wouldn't want to go from SQL->Excel->SQL if you have no other reason for the data to exist in Excel.
Here is some information on creating a windows service:
Easiest language for creating a Windows service
Here is a simple tutorial on accessing SQL in C#: http://www.codeproject.com/Articles/4416/Beginners-guide-to-accessing-SQL-Server-through-C
If you want a more formal solution (read: data access layer), I'd point you toward Entity Framework. The complexity of the project will probably be the driving factor on whether you just want to do SQL statements in your code vs. going with a full blown DAL.
I wonder what you are using for updating a client database when your program is patched?
Let's take a look at this scenario:
You have a desktop application (.net, entity framework) which is using sql server compact database.
You release a new version of your application which is using extended database.
The user downloads a patch with modified files
How do you update the database?
I wonder how you are doing this process. I have some conception but I think more experienced people can give me better and tried solutions or advice.
You need a migration framework.
There are existing OSS libraries like FluentMigrator
project page
wiki
long "Getting started" blogpost
Entity Framework Code First will also get its own migration framework, but it's still in beta:
Code First Migrations: Beta 1 Released
Code First Migrations: Beta 1 ‘No-Magic’ Walkthrough
Code First Migrations: Beta 1 ‘With-Magic’ Walkthrough (Automatic Migrations)
You need to provide explicitly or hidden in your code DB upgrade mechanism, and - thus implement something like DB versioning chain
There are a couple of aspects to it.
First is versioning. You need some way of tying teh version of teeh db to the version of the program, could be something as simple as table with a version number in it. You need to check it on executing the application as well.
One fun scenario is you 'update' application and db successfully, and then for some operational reason the customer restores a previous version of the db, or if you are on a frequent patch cycle, do you have to do each patch in order or can thay catch up. Do you want to deal with application only or database only upgrades differently?
There's no one right way for this, you have to look at what sort of changes you make, and what level of complexity you are prepared to maintain in order to cope with everything that could go wrong.
A couple a of things worth looking at.
Two databases, one for static 'read-only' data, and one for more dynamic stuff. Upgrading the static data, can then simply be a restore from a resource within the upgrade package.
The other is how much can you do with meta-data, stored in db tables. For instance a version based xsd to describe your objects instead of a concrete class. That's goes in your read only db, now you've updated code and application with a restore and possibly some transforms.
Lots of ways to go, just remember
'users' will always find some way of making you look like an eejit, by doing something you never thought they would.
The more complex you make the system, the more chance of the above.
And last but not least, don't take short cuts on data version conversions, if you lose data integrity, everything else you do will be wasted.
I am looking for a way to backup/export my data from Sql Azure onto a local computer.
I would like to integrate it into my existing program.
I know there is now the DAC framework. However it still seems to have its own issues so I'd like to hold off on it in the mean time.
The Sql Azure Migration Wizard seems to do everything I need and does it pretty well.
Copy data Structure to a plain SQL file
Copy all of the data with BCP
However the architecture is tightly coupled to Windows Forms and the separation of concerns is confusing and there seams to be duplication of code between the BatchExport project and WizardProject because basic functionality is mixed presentation code.
Has anyone created something similar that can be used as a library? Or created a branch off that project with the functionality separated from the presentation?
Thank you
Enzo Backup has a reasonable price and you can test a trial version: Enzo Backup Information
I've added a service based database to my solution.
So, it's working on my system and everything is dandy. However this program will have to run on many many machines all independent to each other (meaning they don't connect or even know they exists) I'm selling the application to different people all over my country.
What exactly do I have to do so my application has access to the database design and uses it?
I might be asking the wrong question, but hopefully with my use case you can guide me. Thanks!
You will need to install the relevant database engine with the correct service name, and create the database and relevant objects on installation.
Overall probably not a good solution unless you really need a fully fledged database engine, and even then i local database might be easier.
Bear in mind that the installation of a serious database engine often has complication which would baffle the average PC user.
Can't you use something like sqllite, or berkelydb?
What exactly are the requirements?