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
Related
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.
All other applications I've written have been network/web apps where I've used an SQL database to store data and that has made sense to me.
If I'm creating an application that does not need to be networked ever, is there a standard way to store this data permanently? A text file is possible, but doesn't give me the benefits of querying an SQL server nor is it very secure. Is there something similar to an SQL server that I can initiate and save on starting up my program?
Perhaps there is some structure I've never come across?
From what I've read I might be able to do something as mentioned above like with SQLite. Does that make sense for large and distributed applications?
Thanks in advance for any clarifications on how to design these types of programs.
Edit: to clarify what #TomTom was saying, it is not a large amount of data like he is suggesting. I would be surprised if it ever got over several gigs of data. My point in saying large was that it seemed unreasonable to create some sort of a data structure that I could save into a text file, load up/search through to grab my data compared to using an SQL-like database.
Reading through the answers apparently SQLite or something similar is reasonable to use for desktop applications. I'll continue looking into it and probably use it to track data for my next project.
You can use an embedded database - this can be a SQL database, but does not have to be.
For windows, look at SQLite, SQL Server Compact and RavenDB (for a non SQL, document database).
You could still use SQL database, but locally. Try SQLite.
Other option to use Windows built-in database engine which name is Esent. Fast, but not really convenient to use its Api.
I use SP and linq and Function for work to SQL Server 2005
I want to any connection to DB.
The DB added that the information be deleted or edited or added(to DB) in a text file(log) or do anything to follow events held in the DB.
how can this work by SQL or asp.net
I like in any connection to DB save input/output connection
input:arguman that send to DB
output:DB Return or edit or delete recorded in DB
The question is a little hard to follow, but if you simply want to log all LINQ access to the DB, then with something like LINQ-to-SQL you could use DataContext.Log and specify a writer (be careful though - don't give it the file directly, as you'll block parallel activity).
I personally think this is a bad idea though - data volume is usually prohibitive for this. Databases get very busy.
If that isn't sufficient, and you have other operations to log - you could try an intercepting DbConnection, a bit like the profiled connection in mvc-mini-profiler. This works well with LINQ-to-SQL (EF... harder). But again - data volume is a big issue here.
Create your own small API like OpenDBConnection(); CloseDBConnection(); and use it all arround the code inyour C# program . Add log functionality to that methods and you basically done.
As #Marc says the amount of the data is one of the problems here not actually an implementation, but it depends on current and future scale of your project that only you may know.
Hope this helps.
Regards.
This questions actually refers to another one already asked, now I want to reformulate it :)
My issue is: There is an online shop running on MySQL database, hosted somewehre on the internet. Now I'd like to do some administration stuff from my C# application.
What I want to do: All I want is to run SQL-queries on that database and get the results as entities in my application so I can browse through them like through normal Lists/Classes and then post back the changes to the database. The problem is not the connection to the database - it works fine (using SSH and Connector/NET driver) - but the question, how to turn the SQL-results into C# classes.
I had a closer look at Fluent NHibernate and SubSonic, but I still can't figure out which one suits best or - even worse - if these are really the right approaches to my problem.
So I don't want to build an application which stores its own data in a database but gets the data it needs from a public database.
I hope I could make myself more clear this time :)
Thanks in advance!
ORM is definitely the way to, because it allows you to abstract your data access.
You may find a code generator helpful (to avoid the repetitive task of writing the classes and all their properties): NHibernate Code Generation.
This way you can still use classic NHibernae instead of Fluent Hibernate, which by the way looks pretty useful.
I am writing a small program for our local high school (pro bono). The program has an interface allows the user to enter school holidays. This is a simple stand alone Windows app.
What format should I use to store the data? A big relational data is obviously overkill.
My initial plan was to store the data in an XML file. Co-workers have been suggesting that I use JSON files, Access Databases, SQL Lite, and SQL Server Express. There was even a suggestion of old school INI files.
Projects like this have a habit of getting bigger, quickly, and if they do your XML file will become complex and a burden to manage.
I would not recommend storing the data in an xml file or json - they are just text files by a different name, all suffering from the same problem - you don't have any control over who edits them.
Use some kind of db, starting from the small ones first (Access, SQLLite)
Edit
Based on your latest comments, roll forward to a point where the users have been using the app for two years.
How much data do you expect to have stored by then?
Will the user(s) need to look back through historic data to see, for example, what they did this time last year
And more so, right now
What is Teacher A doing on Thursday afternoon
Will Teacher B be free to attend event on 15th May 2010?
Can Student C attend event D?
All of these questions/problems are a lot easier/more efficient to handle with SQL. Plus your resulting codebase will make a lot more sense. Traversing XML isn't the prettiest of things to do.
Plus if your user base is familiar with Excel already, linking Excel to a SQL database (and produce custom results) is a lot easier than doing the same with XML.
Have you considered using SQLite? It'll result in a small .s3db file. SQLite is used by all kinds of desktop applications for local storage.
There's a SQLite .NET library that'll allow you to use ADO.NET to CRUD your data.
Check out Mike Duncan's article on how to get started with SQLite in .NET.
I would have to second the Json answer and SQL Lite.
Another option would be to use the built in database that's included in all of windows (since Windows 2000), ESENT. There is a codeplex project to make it easy to work with http://managedesent.codeplex.com/
Hm, obviously SQL Express is a full blown database - otohj it may make sense. Why NOT use a databsae if they already have one ?;)
Otherwise I would possibly go with a XML file.
I would recommend an XML file and a typed dataset.
You will need to figure out where to put the XML file.
Note that if you ever want to allow multiple users to use it, you need to use a database, such as Access or SQL Server.
I'd go for
SQL Server Express (free and full blown relational database)
XML/JSON if you don't want a database (LINQ to XML might be a big help here).
xml files seems to be a good option. using Linq to xml it should be quite easy to read/write the files from objects/to objects. check out XDocument and XElement classes
Access Databases, SQL Lite, and SQL Server Express seens like an overkill. do you really need a database to store a simple calendar data? is your application going to grow?
From "simple stand alone Windows app" it sounds to me like it's not critical. I'd go with whatever is easiest, or what you are most comfortable with. XML is usefully human readable, but a sensibly formatted flat file might be just as sensible.
I'd use serialized classes.
One thing to consider if you use a database instead of a text file of some sort: you're no longer a "simple stand alone Windows app". Now you've (most likely) got an installation program to write.