- Hidden Secrets of Server Explorer
- More Than Information Overload
- Other Tricks You Can Perform
- Server Explorer Summarized
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
More Than Information Overload
At this point, you know that Server Explorer is a literal font of information about the machines to which you have access. However, information is helpful only to a point. Despite the capability to manipulate and change some settings on the remote machine without going to the server, you haven't gained much from Server Explorer except a slight case of information overload. But Server Explorer has a lot more to offer. You can use it to decrease bugs in your applications and speed application development. All you need to know is how to do is drag and drop objects.
Let's say you have a SQL Server database that you want to use within your application. Normally, you'd have to perform some setups and then write some code to make the connection. Server Explorer lets you make the connection without writing a single line of code. This example uses a database called MovieGuide that I put together for test purposes. It's a simple database containing one table, but it demonstrates the power of Server Explorer quite effectively. The following steps show how to set up a connection between a SQL Server database and your application using Server Explorer.
Drag the table, view, or stored procedure that you want to use from Server Explorer to the form or other design element for your application. The Visual Studio IDE contacts the database manager, creates the required connection information, and generates a SqlConnection and SqlDataAdapter for you. These objects appear at the bottom of the design area in graphic form. More important, Visual Studio automatically generates the required code, including the commands that you need to select, insert, update, and delete records.
Right-click sqlDataAdapter1 and choose Generate Dataset from the context menu. You'll see a Generate Dataset dialog box. This dialog box contains settings for creating a dataset or simply adding the database represented by the data adapter to an existing dataset. The dataset and the data adapter maintain a connection but operate independently of each other, to an extent. Because this is a new project, you'll need to add a new dataset.
Click OK. Visual Studio generates a file that describes the dataset, adds some more code to the application, and adds another icon to the growing list at the bottom of the design area. Obviously, you don't know whether any of this will work yet. Therefore, it's time to build something with the data connection that Server Explorer helped create.
-
Add a DataGrid control to the form from the Toolbox. Set the DataSource property to dataSet11 and the DataMember property to the name of the table, view, or stored procedure (ExistingMovies, in this case). You'll notice that the DataGrid now contains all the fields in the table, or at least the fields you selected from the table. Your project should look similar to the one in Figure 2 (your list of fields will differ from mine).
)
Figure
2 A very short setup for a grid-based application.
At this point, you do need to add a little code (with an emphasis on little) to make this example functional. The first thing you need to do is tell the data adapter to fill the dataset with data so it appears onscreen. The best place to perform this task is the constructor. All you need is one line of code, as shown in Listing 1.
Listing 1: Filling the Data Grid with Information
Form1(void)
{
// Standard constructor call.
InitializeComponent();
// Add data to the dataset so it appears in the data grid.
sqlDataAdapter1->Fill(dataSet11);
}
The second thing you need to do is provide code that lets the user make changes. Simply displaying the data onscreen probably won't be enough. The easiest way to make this example fully functional is to add a CurrentCellChanged event handler to dataGrid1. This event fires every time the user changes the cell, so you can update the database after every change. Listing 2 shows the event handler code.
Listing 2: Handling User Changes to a DataGrid
private: System::Void dataGrid1_CurrentCellChanged(
System::Object * sender,
System::EventArgs * e)
{
// Verify the user made a change.
if (!dataSet11->ExistingMovies->GetChanges() == NULL)
{
// If so, perform the update.
sqlDataAdapter1->Update(dataSet11);
}
}
I can hear you saying that this looks way too simple, but it really is all you need. The dataSet11->ExistingMovies->GetChanges() method returns NULL until the user has made some type of change—it doesn't matter what kind of change. As soon as the user has made a change, calling sqlDataAdapter1->Update(dataSet11) sends the change to the database. This example can now add and remove records, as well as perform updates.
Automation is a wonderful thing, but you should have noticed a few problems with this example. For one thing, the code doesn't validate the data. Another problem is that the code hasn't really controlled the items that the user can change, nor does the code include niceties such as a menu. It's possible to automate some of these other areas, but that's something Server Explorer can't do for you. In short, Server Explorer is a tool that helps you get started quickly, but it can do only so much.