| Start |
|---|
| Making a connection to a data source The first step in accessing a data source via ADO is creating an ADO Note that a DSN is not required to connect to a data source via ADO - any data source that has an ODBC provider can be connected to with the appropriate connection string. While specific connection strings for different providers are outside of the scope of this topic, ConnectionStrings.com (opens new window) is an excellent reference for finding the appropriate string for your provider. Note that the database password is included in the connection string in the example above only for the sake of clarity. Best practices would dictate not storing database passwords in code. This can be accomplished by taking the password via user input or using Windows authentication. |
| Creating parameterized commands Any time SQL executed through an ADO connection needs to contain user input, it is considered best practice to parameterize it in order to minimize the chance of SQL injection. This method is also more readable than long concatenations and facilitates more robust and maintainable code (i.e. by using a function that returns an array of In standard ODBC syntax, parameters are given Note that the example below uses the Note: The example above demonstrates a parameterized UPDATE statement, but any SQL statement can be given parameters. |
| Retrieving records with a query Queries can be performed in two ways, both of which return an ADO The first method is to pass the SQL statement directly to the Connection object, and is the easiest method for executing simple queries: The second method is to create an ADO Note that commands sent to the data source are vulnerable to SQL injection, either intentional or unintentional. In general, queries should not be created by concatenating user input of any kind. Instead, they should be parameterized (see Creating parameterized commands (opens new window)). |
| Executing non-scalar functions ADO connections can be used to perform pretty much any database function that the provider supports via SQL. In this case it isn't always necessary to use the Note that commands sent to the data source are vulnerable to SQL injection, either intentional or unintentional. In general, SQL statements should not be created by concatenating user input of any kind. Instead, they should be parameterized (see Creating parameterized commands (opens new window)). RemarksThe examples shown in this topic use early binding for clarity, and require a reference to the Microsoft ActiveX Data Object x.x Library. They can be converted to late binding by replacing the strongly typed references with |
Read Article
https://develop.horje.com/learn/1434/reference