In very short, use and learn ADO.NET for this project.
This is the basic things you would need to do in order to retrieve the results.
- Create connection object, setup your connectionString and connect to your database. (e.g conn.Open())
- Setup a command object and set its CommandText property to the SQL command you said you already have.
- Setup a dataReader as long as you do not want to perform updates to your database.
- Call the executeReader() function in your command object and store the results to the dataReader. (e.g dReader = com.ExecuteReader())
- Print out each result the dataReader gathered, either on listview or listbox or datagridview.
Hope this helps, but I would follow vis's advice first.
I'd like to offer a correction to your perception.. perhaps you use datareader because it is familiar in modus operandi to old style ADO recordsets
To make it easier, here's a quick lowdown on when to use readers and when to use tables:
Use a datareader when you want fast, forward only, non locally cached access to database data. An example would be producing a report in CSV format of certain results from a database statement. You write the query, run it in a reader, enter a loop: read from db, write to file, loop end, close file, close reader and youre done.
Use a datatable when you want fast, random accessible local cache of data that may be updated and sent back to the database. An example would be a datagridview that the user will edit and update. Read the contents of the query into the datatable. Show it to the user, allow them to edit it then return the results
It is possible to perform either scenario with either tech, but if you read a database into a datatable and then write it to file, it's expensive on memory in the client.
It is possible to fill a datagridview using a datareader and indeed a tableadapter will do this anyway, so there's no point reimplementing yourself, functionality that the designer can create for you.
The end result is I would never advocate opening a datareader and reading items from it and storing them into a ListView.Items collection - it's too much like old style VB where the MVC distinction was not apparent. Your program operates on Models (blacks of data) Views (components that show you blocks of data) and Controllers (components that update data). You load data into a Model (datatable), and often the controls that show it also form the basis of the controller, but not always. Suppose you had a grid that lets you view all info about a person but you can only edit some things. You cannot click on the grid, but must use navigator buttons < and > to scroll the results and a textbox to edit.. the grid is a View, the scrollers are Controls as they choose what data you view, and the textbox is a combined view and control because it lets you see the data and edit it
