VB.NET - Exibindo nome de tabelas e campos de um Banco de dados

a

a

In Visual Basic 6.0, a form could be displayed as a modal dialog box by calling the Show method with a parameter of vbModal.

In Visual Basic .NET, the ShowDialog method is used to display a form modally; the Show method is used to display a form non-modally.

In addition, the Visual Basic 6.0 CommonDialog control provided several predefined dialog boxes. In Visual Basic .NET, this control is replaced by the ColorDialog control, the FontDialog control, the OpenFileDialog control, the PageSetupDialog control, the PrintDialog control, the PrintPreviewDialog control, and the SaveFileDialog control.

a

Dialog boxes are displayed modally to prevent users from performing tasks outside of the dialog box. For more information on modal and modeless dialog boxes, see Displaying Modal and Modeless Windows Forms.

To create a dialog box at design time

1. Add a form to your project by right-clicking the project in Solution Explorer, pointing to Add, and then clicking Windows Form.
2. Right-click the form in Solution Explorer and choose Rename. Rename the form "DialogBox.vb" or "DialogBox.cs" as appropriate.
3. In the Properties window, change the FormBorderStyle property to FixedDialog.
4. Customize the appearance of the form as needed.
5. Set the ControlBox, MinimizeBox, and MaximizeBox properties to false.

   Dialog boxes do not usually include menu bars, window scroll bars, Minimize and Maximize buttons, status bars, or sizable borders.

6. Customize event methods in the Code Editor. For more information, see Closing Dialog Boxes and Retaining User Input.

Additionally, the .NET Framework has a number of pre-formatted dialog boxes that you can implement for basic tasks within your application that involve user input (opening files, printing files, saving files). For more information, see Dialog Box Controls and Components (Windows Forms).

a

Forms and dialog boxes are either modal or modeless. A modal form or dialog box must be closed or hidden before you can continue working with the rest of the application. For more information about working with dialog boxes, see User Input to Dialog Boxes.

Dialog boxes that display important messages should always be modal. The About dialog box in Visual Studio is an example of a modal dialog box. MessageBox is a modal form you can use.

Modeless forms let you shift the focus between the form and another form without having to close the initial form. The user can continue to work elsewhere in any application while the form is displayed.

Modeless forms are harder to program, because users can access them in an unpredictable order. You have to keep the state of the application consistent no matter what the user does. Often, tool windows are shown in a modeless fashion. The Find dialog box, accessible from the Edit menu in Visual Studio, is an example of a modeless dialog box. Use modeless forms to display frequently used commands or information

a

A declaration specifies the access types of the entity it declares. An entity's access type does not change the scope of an entity's name. The accessibility domain of a declaration is the set of all declaration spaces in which the declared entity is accessible.

The five access types are Public, Protected, Friend, Protected Friend, and Private. Public is the most permissive access type, and the four other types are all subsets of Public. The least permissive access type is Private, and the four other access types are all supersets of Private.

The access type for a declaration is specified via an optional access modifier, which can be Public, Protected, Friend, Private, or the combination of Protected and Friend. If no access modifier is specified, the default access type depends on the declaration context; the permitted access types also depend on the declaration context.

• Entities declared with the Public modifier have Public access. There are no restrictions on the use of Public entities.
• Entities declared with the Protected modifier have Protected access. Protected access can only be specified on members of classes (both regular type members and nested classes). A Protected member is accessible to a derived class, provided that either the member is not an instance member, or the access takes place through an instance of the derived class. Protected access is not a superset of Friend access.
• Entities declared with the Friend modifier have Friend access. An entity with Friend access is accessible only within the program that contains the entity declaration.
• Entities declared with the Protected Friend modifiers have the union of Protected and Friend access.
• Entities declared with the Private modifier have Private access. A Private entity is accessible only within its declaration context, including any nested entities.

The accessibility in a declaration does not depend on the accessibility of the declaration context. For example, a type declared with Private access may contain a type member with Public access.

The following code demonstrates various accessibility domains:

Public Class A
   Public Shared X As Integer
   Friend Shared Y As Integer
   Private Shared Z As Integer
End Class

Friend Class B
   Public Shared X As Integer
   Friend Shared Y As Integer
   Private Shared Z As Integer
   
   Public Class C
      Public Shared X As Integer
      Friend Shared Y As Integer
      Private Shared Z As Integer
   End Class
   
   Private Class D
      Public Shared X As Integer
      Friend Shared Y As Integer
      Private Shared Z As Integer
   End Class
End Class

The classes and members have the following accessibility domains:

• The accessibility domain of A and A.X is unlimited.
• The accessibility domain of A.Y, B, B.X, B.Y, B.C, B.C.X, and B.C.Y is the program text of the containing program.
• The accessibility domain of A.Z is the program text of A.
• The accessibility domain of B.Z and B.D is the program text of B, including the program text of B.C and B.D.
• The accessibility domain of B.C.Z is the program text of B.C.
• The accessibility domain of B.D.X, B.D.Y, and B.D.Z is the program text of B.D.

As the example illustrates, the accessibility domain of a member is never larger than that of a containing type. For example, even though all X members have Public declared accessibility, all but A.X have accessibility domains that are constrained by a containing type.

AccessModifier ::= Public | Protected | Friend | Private

See Also

a

Provides a means of automatically generating single-table commands used to reconcile changes made to a DataSet with the associated database. This class cannot be inherited.

For a list of all members of this type, see OleDbCommandBuilder Members.

System.Object
   System.MarshalByRefObject
      System.ComponentModel.Component
         System.Data.OleDb.OleDbCommandBuilder

[Visual Basic]
NotInheritable Public Class OleDbCommandBuilder
   Inherits Component

[C#]
public sealed class OleDbCommandBuilder : Component

[C++]
public __gc __sealed class OleDbCommandBuilder : public Component

[JScript]
public class OleDbCommandBuilder extends Component

Thread Safety

Any public static (Shared in Visual Basic) members of this type are safe for multithreaded operations. Any instance members are not guaranteed to be thread safe.

Remarks

The OleDbDataAdapter does not automatically generate the SQL statements required to reconcile changes made to a DataSet with the associated data source. However, you can create an OleDbCommandBuilder object to automatically generate SQL statements for single-table updates if you set the SelectCommand property of the OleDbDataAdapter. Then, any additional SQL statements that you do not set are generated by the OleDbCommandBuilder.

The OleDbCommandBuilder registers itself as a listener for RowUpdating events whenever you set the DataAdapter property. You can only associate one OleDbDataAdapter or OleDbCommandBuilder object with each other at one time.

To generate INSERT, UPDATE, or DELETE statements, the OleDbCommandBuilder uses the SelectCommand property to retrieve a required set of metadata automatically. If you change the SelectCommand after the metadata has is retrieved (for example, after the first update), you should call the RefreshSchema method to update the metadata.

The OleDbCommandBuilder also uses the Connection, CommandTimeout, and Transaction properties referenced by the SelectCommand. The user should call RefreshSchema if any of these properties are modified, or if the SelectCommand itself is replaced. Otherwise the InsertCommand, UpdateCommand, and DeleteCommand properties retain their previous values.

If you call Dispose, the OleDbCommandBuilder is disassociated from the OleDbDataAdapter, and the generated commands are no longer used.

Example

[Visual Basic, C#] The following example uses the OleDbCommand, along OleDbDataAdapter and OleDbConnection, to select rows from a data source. The example is passed an initialized DataSet, a connection string, a query string that is an SQL SELECT statement, and a string that is the name of the data source table. The example then creates an OleDbCommandBuilder.

[Visual Basic] 
Public Function SelectOleDbSrvRows(myDataSet As DataSet, myConnection As String, mySelectQuery As String, myTableName As String) As DataSet
    Dim myConn As New OleDbConnection(myConnection)
    Dim myDataAdapter As New OleDbDataAdapter()
    myDataAdapter.SelectCommand = New OleDbCommand(mySelectQuery, myConn)
    Dim custCB As OleDbCommandBuilder = New OleDbCommandBuilder(myDataAdapter)

    myConn.Open()

    Dim custDS As DataSet = New DataSet
    myDataAdapter.Fill(custDS, "Customers")

    ' Code to modify data in DataSet here 

    ' Without the OleDbCommandBuilder this line would fail.
    myDataAdapter.Update(custDS, "Customers")

    myConn.Close()

    SelectOleDbSrvRows = custDS
End Function 'SelectOleDbSrvRows

[C#] 
public DataSet SelectOleDbSrvRows(DataSet myDataSet,string myConnection,string mySelectQuery,string myTableName) 
{
    OleDbConnection myConn = new OleDbConnection(myConnection);
    OleDbDataAdapter myDataAdapter = new OleDbDataAdapter();
    myDataAdapter.SelectCommand = new OleDbCommand(mySelectQuery, myConn);
    OleDbCommandBuilder custCB = new OleDbCommandBuilder(myDataAdapter);

    myConn.Open();

    DataSet custDS = new DataSet();
    myDataAdapter.Fill(custDS, "Customers");

    //code to modify data in dataset here

    //Without the OleDbCommandBuilder this line would fail
    myDataAdapter.Update(custDS, "Customers");

    myConn.Close();

    return custDS;
 }

[C++, JScript] No example is available for C++ or JScript. To view a Visual Basic or C# example, click the Language Filter button in the upper-left corner of the page.

Requirements

a

a

The Fill method retrieves rows from the data source using the SELECT statement specified by an associated SelectCommand property. The connection object associated with the SELECT statement must be valid, but it does not need to be open. If the connection is closed before Fill is called, it is opened to retrieve data, then closed. If the connection is open before Fill is called, it remains open.

The Fill operation then adds the rows to destination DataTable objects in the DataSet, creating the DataTable objects if they do not already exist. When creating DataTable objects, the Fill operation normally creates only column name metadata. However, if the MissingSchemaAction property is set to AddWithKey, appropriate primary keys and constraints are also created.

If the data adapter encounters duplicate columns while populating a DataTable, it generates names for the subsequent columns, using the pattern "columnname1", "columnname2", "columnname3", and so on. If the incoming data contains unnamed columns, they are placed in the DataSet according to the pattern "Column1", "Column2", and so on. When multiple result sets are added to the DataSet each result set is placed in a separate table. Additional result sets are named by appending integral values to the specified table name (for example, "Table", "Table1", "Table2", and so on.). Applications should use caution when using column and table names to ensure that conflicts with these naming patterns does not occur.

When the SELECT statement used to populate the DataSet returns multiple results, such as a batch SQL statements, if one of the results contains an error, all subsequent results are skipped and not added to the DataSet.

You can use the Fill method multiple times on the same DataTable. If a primary key exists, incoming rows are merged with matching rows that already exist. If no primary key exists, incoming rows are appended to the DataTable.

Note   When handling batch SQL statements that return multiple results, the implementation of FillSchema for the OLE DB .NET Data Provider retrieves schema information for only the first result. To retrieve schema information for multiple results, use Fill with the MissingSchemaAction set to AddWithKey.

a

Até breve , com certeza nos encontraremos pelos caminhos .NET...

José Carlos Macoratti