Read SQL Table into C# DataTable

Here, give this a shot (this is just a pseudocode)

using System;using System.Data;using System.Data.SqlClient;public class PullDataTest{    // your data table    private DataTable dataTable = new DataTable();    public PullDataTest()    {    }    // your method to pull data from database to datatable       public void PullData()    {        string connString = @"your connection string here";        string query = "select * from table";        SqlConnection conn = new SqlConnection(connString);                SqlCommand cmd = new SqlCommand(query, conn);        conn.Open();        // create data adapter        SqlDataAdapter da = new SqlDataAdapter(cmd);        // this will query your database and return the result to your datatable        da.Fill(dataTable);        conn.Close();        da.Dispose();    }}

var table = new DataTable();    using (var da = new SqlDataAdapter("SELECT * FROM mytable", "connection string")){          da.Fill(table);}

Lots of ways.

Use ADO.Net and use fill on the data adapter to get a DataTable:

using (SqlDataAdapter dataAdapter    = new SqlDataAdapter ("SELECT blah FROM blahblah ", sqlConn)){    // create the DataSet     DataSet dataSet = new DataSet();     // fill the DataSet using our DataAdapter     dataAdapter.Fill (dataSet);}

You can then get the data table out of the dataset.

Note in the upvoted answer dataset isn't used, (It appeared after my answer)It does

// create data adapterSqlDataAdapter da = new SqlDataAdapter(cmd);// this will query your database and return the result to your datatableda.Fill(dataTable);

Which is preferable to mine.

I would strongly recommend looking at entity framework though ... using datatables and datasets isn't a great idea. There is no type safety on them which means debugging can only be done at run time. With strongly typed collections (that you can get from using LINQ2SQL or entity framework) your life will be a lot easier.

Edit: Perhaps I wasn't clear: Datatables = good, datasets = evil. If you are using ADO.Net then you can use both of these technologies (EF, linq2sql, dapper, nhibernate, orm of the month) as they generally sit on top of ado.net. The advantage you get is that you can update your model far easier as your schema changes provided you have the right level of abstraction by levering code generation.

The ado.net adapter uses providers that expose the type info of the database, for instance by default it uses a sql server provider, you can also plug in - for instance - devart postgress provider and still get access to the type info which will then allow you to as above use your orm of choice (almost painlessly - there are a few quirks) - i believe Microsoft also provide an oracle provider. The ENTIRE purpose of this is to abstract away from the database implementation where possible.