1.1

VMware.Data.SQLFire.SQLFCommand
VMware.Data.SQLFire.SQLFCommand executes SQL commands and reads results, if any, as a scalar value or
by using a VMware.Data.SQLFire.SQLFDataReader. This class implements ADO.NET's
System.Data.IDbCommand interface and extends the abstract System.Data.Common.DbCommand class.
An object of this class bound to SQLFClientConnection is returned by the CreateCommand() method of the
SQLFClientConnection class. When using that method, the ConnectionText property of the command must be
set to a valid SQL statement before execution of the command.
• Constructor on page 670
• Named and positional parameters in commands on page 670
• Prepare() on page 671
• Batch operations using SQLFCommand on page 671
• Additional SQLFire extensions on page 672
• Example: Using positional parameters on page 673
• Example: Using named parameters on page 673
• Example: Using both positional and named parameters on page 674
• Example: Using parameterized commands for batch operations on page 675
• Example: Using commands having no parameters for batch operations on page 675
Constructor
SQLFCommand(string commandText, SQLFConnection connection) initializes a new command object with
given SQL command text. The connection parameter requires a SQLFConnection class object which is currently
implemented only by SQLFClientConnection.
Named and positional parameters in commands
You can provide parameters to SQLFCommands in two forms:
• As VMware.Data.SQLFire.SQLFParameters
• Directly as raw .NET objects in the parameter collection (the Parameters property of the command object)
In the latter case the driver automatically determines the type, size, precision, and other applicable parameters.
In either case the SQLFire servers try to convert the parameter type to the actual type (as determined from table
column types and so forth, per SQL rules), or return an exception if the conversion fails. With SQLFParameter,
the expected type of parameter must match the SQLFType of the parameter, if specified. With raw objects, the
type used is the default one as per the type of the .NET class of the object. See the table in
VMware.Data.SQLFire.SQLFType on page 676 for the mapping of .NET object classes to corresponding SQL
types.
Second option (named parameters) is to refer to the parameters by the name of the parameter prefixed with a “:”
in which case the parameters are bound by the matching name, if any, in the SQLFParameterCollection list of
a VMware.Data.SQLFire.SQLFParameter. In this case the position of the parameter in the parameter list is
immaterial and name alone decides the parameter to be bound. There is no provision to use raw objects as
parameters for this option because objects as such have no associated names.
It is also possible to use a combination of the above two approaches, with some parameters bound by name while
others are bound by wildcard. The named parameters are first bound by the respective names, and the remaining
parameters are bound by their position in the parameter list. This approach is not recommended due to possibility
of ambiguities and lack of clarity.
Using positional parameters with wildcards is a bit faster than using named parameters, although the difference
is negligible. However, the wildcard approach also allows raw objects directly as parameters so can have some
benefit in terms of smaller number of objects being created and collected by the GC.
vFabric SQLFire User's Guide670
vFabric SQLFire Reference