I just started working with SQL and now what I need is to make a database for my C# application which will save user names and passwords. Think of it like a password reminder.
Anyway, what I think I need to do is: I need to create a SQL database which will the application only use to save data. It should not need SQL Server to be installed on the machine.
I searched over the internet but no result, all of them require the use of SQL Server, please could you just provide me the steps to do so, or any resource and thanks a lot.
You need to decide how you want to save your data. You can save the data in an XML file, a plain text file, or anything else.
The reason you're seeing so many examples of people using SQL is because relational databases have already solved a lot of the issues you're likely to run into when storing and retrieving data. That means in most cases, it's much easier to use an SQL database (even a lightweight embedded one) than to try to come up with your own library for retrieving and saving data.
A note about saving passwords
Bear in mind that any data you save on a client's computer is going to be accessible to that client. You can use tricks to make it very difficult for someone to get to that data, but there's nothing your program can do that a clever hacker won't be able to mimic. The only way to avoid letting users see the stored passwords would be to make the user provide a "master" password that gets converted into a key that is used to encrypt the other passwords. This way, only users that know this master password would still be able to get the stored data.
Storing data in a relational database is not sufficient to prevent users from accessing that data.
You could use SQL Compact ( http://msdn.microsoft.com/en-us/data/ff687142 ) to avoid installing SQL Server.
You could also go for sqlite.org.
Your requirements of "I want a database" and "I don't want [database]-server" are difficult to match.
If you have a database without a database-server, you have a lump of in-accessible data.
If you want to use a SQL database, you will need a SQL server. Or, you will have to re-implement one in order to use the database.
There are a number of small, open-source SQL servers available. I've worked with HSQL.
you might want to take a look at the SO question SQL-lite vs HSQL-db.
If all you want is one file that can't be read easily, try encrypting the data, and use either text or XML files for storage.
You do need a database to be installed on your computer if you want to use SQL to query the data. It need not be SQL Server, but definitely some kind of database. You can download MySQL, Sql Server Express or any of the free database products available out there.
Once you have that up and running, querying the database from c# is fairly simple and it may be easier for you to follow this tutorial, with has similar functionality to what you need.
You could always use a CSV (Comma Separated Value) file as your "database" I found a link that could help you with this Query CSV using LINQ C# 2010
EDIT: When it comes to security, you can always use something like MD5. It can turn a password into a an irreversible hash. This way no one will ever be able to see others passwords
Related
My WinForms C#/.NET application requires a table/grid control to display records to the end user. The records will be simple, containing only two fields, a string and a date/time field. I need to persist the data and I am wondering what the most efficient control and storage back-end is to use. The data is non-critical (i.e. - not health or financial records, or anything sensitive requiring extensive safety or any encryption).
One solution I have found so far is the DataGrid control in conjunction with SQL Server Compact Edition. I learned about this solution from this tutorial:
http://www.dotnetperls.com/datagridview-tutorial
It seems though that this may be overkill for my application. In addition, I am worried about the complexities of installing SQL Server CE, especially when it comes to admin vs. user account privilege issues during installation:
http://msdn.microsoft.com/en-us/library/aa983326(v=vs.80).aspx
Is there a table or grid control with built-in file load/save capabilities that uses a simple disk file as the storage method, perhaps a comma delimited ASCII file? I'd like something that I can still use SQL (via LINQ) to interface with. also, I am hoping that this can be done transparently. That is, if I want to upgrade to an SQL database engine solution later, the code from my end that interfaces with the data would not change (except perhaps for the database open/create code of course).
Or am I better off simply biting the bullet and going with SQL Server CE or perhaps SQLite:
Good embedded database solution (like SQLite) for .Net
If you have any caveats or anecdotes regarding installation issues and ease of use, they would be appreciated.
In my projects, we use Object datasources. Grid's can be bound to collections of objects just as easily as they can dataTables. You can store/restore the data using a simple serialization engine (XmlSerializer is rather easy to implement). Make a basic object, use List or BindingList as the dataset, and serialize/de-serialize it in the backEnd when you need it.
List and BindingList both support Linq queries.
Adding database save later is as simple as writing the code that saves the object to the database, in place of the serialization code, no change to the front end at all.
As far as a "Correct" solution is concerned...there are so many different ways to do it that it boils down to personal preference, and possibly actual requirements and expected future development. I find it easier to code using objects because the data manipulation is easier, but if you are going for straight record entry, no data manipulation required, going direct to a database is easier. It just depends on the data and what you plan on doing with it.
I strongly recommend you to use an embedded database, because it will be easier to go to a full database in a near future. SQL Server CE is a good option, and if you want to go big you can simply go to a full SQL Server Database with minimal changes in your code, the only downside of SQL Server CE is that you need to install it and it requires the .NET Framework 4, aside from that I don't see a big problem with it.
I'm currently developing app that requires storage of lots of information from different controls. I've never done this before, and after reading couple things on this topic got a little confused. Do I need to download SQL server 2008 and work with it in order to store data from WinForm? If yes, then what is the service-side item for? Can I use for storage?I don't need to import data from database(at least not for now), I just need stuff to save somewhere, and I would like to know where exactly. Thank you!
You can choose to store your data in a serverless database (SQL CE, SQLite for example) if you don't need fancy database stuff like stored procedures, weird indexes etc. Both of the above mentioned technologies are compatible with Entity Framework, hence you can use code first approach (you can write the classes and the database would be generated on the fly).
here you can read more about it.
http://www.codeproject.com/Articles/318010/Entity-Framework-Code-First-Let-s-Try-It
And here's SQLite assembly for .Net
http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
Good luck
You don't have to store anything in a database, you could for example serialize whatever you need to store into isolated storage
I have read one line from your question " SQL server 2008 and work with it in order to store data from WinForm"; Mean you want to save some data and that will be coming from data entry from winform.. RIght?
If that is the case you can adopt any of the RDBMS software that suites your finance + capacity needs and other perameters.
You can surely go for SQL server 2008 or Oracle or MySql or (List will go one).
What is the nature of your data?
Just because it's big does not necessarily mean a full-blown DBMS (or even an embedded database) is the best fit. Have you considered simply serializing the data to plain files?
But if your data is "relational" and you need to do the things such as querying, integrity enforcement, transactions, concurrent access by multiple clients (etc..), then you should definitely consider a database approach, including MS SQL Server, Oracle, IBM DB2, Sybase etc...
There are good open-source DBMSes as well: PostgreSQL, Firebird, MySQL...
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 am in the midst of writing a small program (more to experiment with vs 2010 than anything else)
Despite being an experiment it has some practical use for our local athletics club.
My thought was to access the DB (currently online) to download the current members and store locally on a laptop (this is a MS sql table, used to power the club's website).
Take the laptop to the event (yes there ARE places that don't have internet coverage), add members to that days race (also a row from a sql table (though no changes would be made to this), record results (new records in 3rd table)
Once home, showered and within internet access again, upload/edit the tables as per the race results/member changes etc.
So I was thinking I'd do something like write xml files locally with the data, including a field to indicate changes etc?
If anyone can point me in a direction I would appreciate it...hell if anyone could tell me if this has a name, I'd appreciate it.
Essentially what you need is, in addition to your remote data store, a local data store on your desktop. You could then write your code by hand to sync the data stores when you go offline / online, or you could use the Microsoft Sync framework to handle it for you.
I've personally used the Sync framework on a number of projects and once you get used to the conventions, it's pretty easy to use.
If a local storage format is what your after. SQLite is one option. You can copy your tables from the server to your local SQLite db.
You could also save your data to files, but XML is a horrible format for doing this. You'll probably want to use YAML or JSON instead.
You may want to take a look at SQL Server Compact -- it provides some decent capabilities with synchronizing back with the mothership SQL server.
If you're using MS SQL Server for production, and you only need to work offline on your personal computer, you could install MS SQL Server Express locally. The advantage here over using a different local datastore is that you can reuse your schema, stored procedures, etc. essentially only needing to change the connection string to your application (which you could run locally too through Visual Studio). You would have to write code to manually sync your online and offline db instances, but since it's a small application, it may be reasonable to just copy the entire database from production to local and then from local to production when you get home (assuming you're the only one updating the db, and wouldn't be potentially wiping out any new records entered in production while you were at the event).
Google Gears http://gears.google.com/ is intended if your app is a web app (which I didn't quite get what it is from your description)
I have two databases, one is an MS Access file, the other is a SQL Server database. I need to create a SELECT command that filters data from the SQL Server database based on the data in the Access database. What is the best way to accomplish this with ADO.NET?
Can I pull the required data from each database into two new tables. Put these in a single Dataset. Then perform another SELECT command on the Dataset to combine the data?
Additional Information:
The Access database is not permanent. The Access file to use is set at runtime by the user.
Here's a bit of background information to explain why there are two databases. My company uses a CAD program to design buildings. The program stores materials used in the CAD model in an Access database. There is one file for each model. I am writing a program that will generate costing information for each model. This is based on current material prices stored in a SQL Server database.
My Solution
I ended up just importing the data in the access db into a temporary table in the SQL server db. Performing all the necessary processing then removing the temporary table. It wasn't a pretty solution but it worked.
You don't want to pull both datasets across if you don't have to do that. You are also going to have trouble implementing Tomalak's solution since the file location may change and might not even be readily available to the server itself.
My guess is that your users set up an Access database with the people/products or whatever that they are interested in working with and that's why you need to select across the two databases. If that's the case, the Access table is probably smaller than the SQL Server table(s). Your best bet is to pull in the Access data, then use that to generate a filtered query to SQL Server so that you can minimize the data that is sent over the network.
So, the most important things are:
Filter the data ON THE SERVER so that you can minimize network traffic and also because the database is going to be faster at filtering than ADO.NET
If you have to choose a dataset to pull into your application, pull in the smaller dataset and then use that to filter the other table.
Assuming Sql Server can get to the Access databases, you could construct an OPENROWSET query across them.
SELECT a.*
FROM SqlTable
JOIN OPENROWSET(
'Microsoft.Jet.OLEDB.4.0',
'C:\Program Files\Microsoft Office\OFFICE11\SAMPLES\Northwind.mdb';'admin';'',
Orders
) as b ON
a.Id = b.Id
You would just change the path to the Access database at runtime to get to different MDBs.
First you need to do something on the server - reference the Access DB as a "Linked Server".
Then you will be able to query it from within the SQL server, pulling out or stuffing in data however you like. This web page gives a nice overview on how to do it.
http://blogs.meetandplay.com/WTilton/archive/2005/04/22/318.aspx
If I read the question correctly, you are NOT attempting to cross reference across multiple databases.
You need merely to reference details about a particular FILE, which in this case, could contain:
primary key, parent file checksum (if it is a modification), file checksum, last known author, revision number, date of last change...
And then that primary key when adding information obtained from analysing that file using your program.
If you actually do need a distributed database, perhaps you would prefer to use a non-relational database such as LDAP.
If you can't use LDAP, but must use a relational database, you might consider using GUID's to ensure that your primary keys are good.
Since you don't give enough information, i'm going to have to make some assumptions.
Assuming:
The SQL Server and the Access Database are not on the same computer
The SQL Server cannot see the Access database over a file share or it would be too difficult to achieve this.
You don't need to do joins between the access database and the sql server, only use data from teh access database as lookup elements of your where clause
If the above assumptions are correct, then you can simply use ADO to open the Access database and retrieve the data you need, possibly in a dataset or datatable. Then extract the data you need and feed it to a different ADO query to your SQL Server in a dynamic Where clause, prepared statement, or via parameters to a stored procedure.
The other solutions people are giving all assume you need to do joins on your data or otherwise execute SQL which includes both databases. To do that, you have to use linked databases, or else import the data into a table (perhaps temporary).
Have you tried benchmarking what happens if you link from the Access front end to your SQL Server via ODBC and write your SQL as though both tables are local? You could then do a trace on the server to see exactly what Jet sends to the server. You might be surprised as to how efficient Jet is with this kind of thing. If you're linking on a key field (e.g., and ID field, whether from the SQL Server or not), it would likely be the case that Jet would send a list of of the IDs. Or you could write your SQL to do it that way (using IN SELECT ... in your WHERE clause).
Basically, how efficient things will be depends on where your WHERE clause is going to be executed. If, for instance, you are joining a local Jet table with a linked SQL Server table on a single field, and filtering the results based on values in the local table, it's very likely to be extremely efficient, in that the only thing Jet will send to the server is whatever is necessary to filter the SQL Server table.
Again, though, it's going to depend entirely on exactly what you're trying to do (i.e., which fields you're filtering on). But give Jet a chance to see if it is smart, as opposed to assuming off the bat that Jet will screw it up. It may very well require some tweaking to get Jet to work efficiently, but if you can keep all your logic client-side, you're better off than trying to muck around with tracking all the Access databases from the server.