In the ado.net parameters often need to deal with a variety of databases, in the case of not practical stored procedures, the use of parameterized SQL statements to some extent to prevent SQL injection, while some of the more difficult to assign the field using parameterized SQL statements can easily be assigned.
So I often in ado.net parameterized SQL statements, in recent years with the SQL Server/oracle/mysql/access deal with, accumulated some experience, now sorted out for everyone's reference. We assume that the data can be structured as shown below (the database set is oracle10g):
CREATE TABLE S_admin
UserName varchar NOT NULL,
Password varchar NOT NULL,
Remarkvarchar (m) NULL,
Mail varchar () NOT NULL,
adddate datetime NULL Default GETDATE (),
Logindatedatetime null default GETDATE (),
Loginip varchar (m) NULL,
Activesmallint NULL default 1,
Logincount intnull default 1,
Power intnull Default 0,
Departid intnull Default 0,
Constraint Pk_s_admin primary key nonclustered (USERID)
Go requires that, in addition to access, manipulating other databases does not have to be added in the order in which they appear in the SQL statement, but in Access you must add parameters in the order in which the columns are inserted, because the OLE db.net Framework The data provider uses positional parameters labeled question marks (?) instead of named parameters (MSDN), so adding parameters and assigning values must be in the order of the columns.
Through the example above, basically, a rule can be summed up: The format of the parameter names in parameterized SQL is consistent with the life stored procedure parameters in the stored procedure, for example, stored procedure parameters in Oracle begin with ":", and stored procedure parameters in MS SQL Server are all preceded by "@", And in MySQL stored procedures (MySQL from 5.0 version to support stored procedures) parameters are "?
", so the parameter names are somewhat different in the parameterized SQL statement (remember a friend on Csdn who didn't know why"? "is used in parameterized SQL statements in MySQL). Instead of using "@" like SQL Server, if that friend had read this, I think he would have solved the doubt.