Questions and Answers about .NET
|
Please give me a reasonably thorough explanation of Command objects.
|
||||||||||||||||||||||||||||||||||||||||||||||||
| A Command is one object removed from a database in the
ADO.NET object model. First, a Connection points at a database. Then, a
Command wraps a SQL statement and directs the statement to a Connection.
In this way, you can use a Command to execute SQL statements for the
database at which a Connection points. Different Command methods are tuned
for specific kinds of tasks. The ExecuteNonQuery Command method is especially well suited for implementing SQL data definition statements. This article’s samples demonstrate the creation and management of logins, databases, and tables. However, the ExecuteNonQuery method is good for any situation when you do not need to return any values from a Command. You have probably already discovered its power for data manipulation in combination with stored procedures and parameters. When return values from a Command is your goal, then consider the ExecuteReader and ExecuteScalar methods. The ExecuteReader method provides a forward-only, read-only way of accessing data. Actually, this method returns a Data Reader. The Data Reader returns a stream of bytes from a database. You have to know the structure of the bytes, such as the data types for column values, to use a Data Reader. Data Reader provide super fast access to data because of their low processing requirements. When you just want one value, such as an aggregate, then the ExecuteScalar method is the tool of choice. Instead of processing a stream of values, the ExecuteScalar method returns just one value – even when a Command returns more than one value. Commands for SQL Server even offer an ExecuteXMLReader method for reading data returned by SELECT statements with a FOR XML clause. This article features the use of Commands based on SQL statements. Developers can enable users to input values that contribute to the design of a SQL statement at run time. This approach is very robust, but it is also vulnerable to abuse by hackers. When accepting strings for SQL in applications, it is imperative to verify that hackers are not passing in code that can alter the intended use of your application. This is not a difficult task. Hackers are merely inputting text that you can examine before executing it with a Command. In order to keep the focus on Commands, this article does not present SQL string validation techniques. |
|||||||||||||||||||||||||||||||||||||||||||||||||
|
I am confused about how to match up Visual Basic .NET data types with Access data types. Can you help? | ||||||||||||||||||||||||||||||||||||||||||||||||
Here'a a table that matches Visual Basic .NET types with
Access data types.
|
|||||||||||||||||||||||||||||||||||||||||||||||||
|
How does the Option Strict statement in Visual Basic .NET compare to the Option Explicit statement in classic Visual Basic? | ||||||||||||||||||||||||||||||||||||||||||||||||
| The Option Strict statement is a statement introduced with
Visual Basic .NET. Just as with the Option Explicit statement available
with classic Visual Basic, you must specify this directive as the first
line of any code module. You can set the Option Strict to either On or Off
by following the statement with the On or Off keyword. It is Off by
default. While you can still use Option Explicit to require the
explicit declaration of variable data types, the new Opton Strict
directive implies Option Explicit. In addition, the Option Strict
directive governs how you can specify the input and output values from
procedures. The use of the Option Explicit directive does not result in
sensitivity to explicit type declarations for input and output arguments
for procedures. The Option Strict On directive allows only widening data type conversions. These are conversions that will surely lead to successful conversion. For example, you can always convert a variable declared as a Byte data type to an Integer data type. This is an example of a widening conversion because there can be no data loss. On the other hand, transforming a variable declared as an Integer type to another variable declared as a Byte data type is a narrowing convention. Since the Integer data type range extends well below and above the range of legitimate values for a Byte data type, it is possible, but not necessary, for the conversion from the Integer data type to the Byte data type to throw a run-time error, which is known in the .NET Framework as an exception. |
