Develop Reference

Building C# and SQL Server database dependant application

Let's say I need to create an application like a books library management system for example that has a front-end like Windows form/WPF and it stores information to database. How to approach making such a solution.
Do we need to create a database first with all tables in C# or is the other way.. SQL to C#?
How do people generally do this? Can someone point me to a sample free project or a book that does this to reinforce my understanding.

Both ways are possible. People usually only focus on one side and use a tool for the other.
Database first approach: Codesmith is an exemple of tool that'll generate C# files after you created the database.
Code first approach: Entity Framework is (an exemple) for the other way around, you write your model in C# and it will generate the database accordingly.
Now pointing you at one or the other would be a bit subjective and also not really match Stack Overflow spirit.

Very basic and simple db file for C# desktop app

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

SQL modules in c#

I am creating a C# application which will have to upload and read data from a SQL database. In school I learned the raw database calls but I am wondering if there is a free tool which lets me work easier and faster with the database call.
I also need to be sure that none is editing on the same line in the table at the same time so it could be nice if the tool also had something to ensure this.
Hope some of you have some great experiences

Take a look at Object Relational Mappers.
The favourites at this time a nHibernate and Entity Framework, but there are many others.

How to use a local database in c#?

I've made a local database for a C# project:
I know basic SQL commands, but haven't worked with databases in C#.
What I'd like to know specifically is:
How to read from the database (query)
How to add and update rows
The database only consists of 3 tables, so I don't think anything fancy is needed.

First, you should learn a bit about various technologies and APIs for connecting with a database.
The more traditional method is ADO.NET, which allows you to define connections and execute SQL queries or stored procedures very easily. I recommend digging up a basic tutorial on ADO.NET using Google, which may differ depending on what type of project you're creating (web app, console, WinForms, etc).
Now days, ORMs are becoming increasingly popular. They allow you to define your object model in code (such as every database table would be a class, and columns would be properties on that class) and bind to an existing database. To add a new row to a table, you'd just create an instance of a class and call a "Save" method when you're done.
The .NET framework has LINQ to SQL and the Entity Framework for this sort of pattern, both of which have plenty of tutorials online. An open source project I really like is Castle Active Record, which is built on top of NHibernate. It makes defining ORMs quite easy.
If you have specific questions about any of the above, don't hesitate to post a new question with more specific inquiries. Good luck!
Update:
I thought I'd also put in one last reference as it seems you might be interested in working with local database stores rather than building a client/server app. SQLite allows you to interact with local stores on the file system through SQL code. There's also a .NET binding maintained by the SQLite guys (which would in theory allow you to work with the other platforms I mentioned): http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki

You can use SQLCE.
This blog will give you a good start.
http://weblogs.asp.net/scottgu/archive/2011/01/11/vs-2010-sp1-and-sql-ce.aspx

Here is a small tutorial that should be helpful to you.
You can make use of the SqlDataReader to read data
and the SqlCommand to Insert Update Delete rows from your tables.
http://www.dotnetperls.com/sqlclient

You could use it by adding following to your Startup.cs
services.AddDbContext<DemoDbContext>(options => options.UseSqlite("Filename=data.db"));

How do I correctly separate the database operations from the gui/logic in c# when working with datasources?

Im having a really hard time figuring out how to specify a good search term for my problem: separation of gui and database interaction in visual studio 2008 using Linq to sql.
According to my teacher in a c# class im taking it's not correct to let the GUI be dependant on a specific way of getting data.
The way my project is currently set up is that we have a mssql database where everything is stored.
The solution is split into 4 seperate projects. UserGUI, AdminGUI, Logic and Db.
Now using linq to populate listboxes and similar things I use something like:
From the windows form in the project UserGUI:
//The activeReservationBindingSource has Db.ActiveReservation as it's value
private void refreshReservation() {
activeReservationBindingSource.DataSource = logic.getActiveReservationsQry();
}
To the Logic project:
public IQueryable getActiveReservationsQry() {
return dbOperations.getActiveReservationsQry(this.currentMemberId);
}
To the database project:
public IQueryable getActiveReservationsQry(int memberId) {
var qry =
from active in db.ActiveReservations
where active.memberId == memberId
orderby active.reservationId
select active;
return qry;
}
This makes sense to me seing as I can send items from listboxes all the way to the database project and there easily update/insert things into the mssql database. The problem is that it would be pretty hard to merge over from a mssql database to lets say an access version.
What should I be reading up on to understand how to do this correctly? Is creating my own classes with the same values as the ones visual studio generates for me when I create the dbml file a way to go? Should I then in the logic project populate for example List that I pass to the GUI? To me it seams like "double work" but perhaps it's the correct way to go?
Be adviced that we have not read anything about design patterns or business logic which seems to be a pretty big subject which im looking forward to exploring outside the frame of the course at a later time.
I was also thinking that IQueryable inherits from IEnumerable and perhaps that was the way to go but I have failed to find any information that made sense to me on how to actually accomplish this.
The GUI also knows about the datasources which I think is a bad thing but can't figure out how to get rid of.
Please understand that I tried to figure this out with my teacher for half an hour today at the only tutoring available for this project and then spent most of the day trying to find similar answers on google, SO and from classmates without any result.

There's a post here that I answered where the question was a bit similar to yours. I think it worth to take a look.
Regards

One keyword to read up on: Model-View-Controller. That's kind of the idea you're after. Your "View" is the GUI. The "Model" is the data layer, and the Controller is the code that takes data from the DB and hands it to the GUI (and vice-versa.)

Check out the repository pattern. There are several implementations you can find by googling "Linq repository."
you may want to check out the MVC Storefront series here: http://www.asp.net/learn/mvc-videos/#MVCStorefrontStarterKit. In the series, Rob Conery builds a Linq IQueryable repository that returns custom made objects instead of the linq objects.

May be you can take a look at Data Abstract

According to my teacher in a c# class im taking it's not correct to let the GUI be dependant on a specific way of getting data.
Honestly your teacher is an idiot. This is one of the stupidest statements, from a database perspective, I've ever read. Of course you want to be dependant on a specific way of getting data if that is the most performant way to get the data (which is almost always database specific and means not using LINQ to SQL for complex queries but that is another who issue). Users care about performance not database independence.
Very few real world applications truly need to be database independant. Yes a few kinds of box software sold commercially are (although I think this is usually a mistake and one reason why every commercial product I've ever used is badly designed and horribly slow).
And since every database implements SQl differntly, even using ANSII sql is not completely database independant. Access in particular is no where near close to the ANSII standard. There is no way to write code which will work correctly on every single possible database.