Nous sommes déjà habitués à effectuer des opérations de base de données dans ASP en appelant des procédures stockées SQL Server, mais savez-vous que nous pouvons également créer et utiliser des procédures stockées dans la base de données Access au niveau du bureau ?
Access + ASP est une excellente combinaison pour développer des applications Web légères : simples, rapides et compatibles, mais les performances ne sont généralement pas élevées. De plus, l'utilisation des objets ADODB.Connection et Recordset pour exécuter des instructions SQL présente certains inconvénients, car les valeurs des paramètres des instructions SQL avec des paramètres sont souvent fusionnées en chaînes, ce qui entraîne des problèmes tels que des guillemets simples. L'un des avantages de l'utilisation de procédures stockées est qu'elles prennent en charge la fourniture supplémentaire de valeurs de paramètres d'instruction SQL.
En fait, les procédures dites stockées dans Access (2000 et versions ultérieures) sont incomparables avec les procédures stockées dans SQL Server. Il ne peut être considéré que comme Stored Procedure Lite, ne prend pas en charge plusieurs instructions SQL, ne prend pas en charge les instructions logiques (haha, ce n'est pas du T-SQL après tout), etc. Je ne sais pas encore s'il est précompilé. Cependant, tout comme les soi-disant classes implémentées par VBScript ne sont qu'encapsulées et favorisent grandement l'embellissement de la structure du code et la réutilisabilité des programmes, les procédures stockées légères d'Access devraient également être utiles pour standardiser et minimiser les opérations de base de données de probabilité d'erreur, et les performances peuvent être améliorées.
Ci-dessous, j'expliquerai étape par étape comment créer une procédure stockée dans Access, puis l'utiliser dans un programme ASP.
(1) Créer une procédure stockée dans Access
Je ne sais pas dans quelle mesure tout le monde utilise Access. Quoi qu'il en soit, pour moi, c'est juste un outil pour créer des fichiers de base de données MDB, puis je crée des tables, des index, des contraintes, etc. fini ~
Les requêtes dans Access jouent le rôle de procédures stockées. Les procédures stockées ou requêtes Access que je mentionne ci-dessous font toutes référence à cette chose.
Pour la création de requêtes, Access fournit un outil insensé, similaire à l'assistant lors de la création d'un DataAdapter dans VS.NET. Mais j'aime écrire du code SQL directement
Cliquez ensuite sur le bouton de requête à gauche sur l’interface Access principale, puis double-cliquez sur Créer une requête en mode Création à droite pour ouvrir la vue Création de requête.
À ce stade, le générateur de requêtes visuelles apparaît. Nous ajoutons d'abord les tables que l'instruction SQL doit impliquer.
Après avoir ajouté la table, cliquez avec le bouton droit sur la vue conception et sélectionnez Vue SQL pour passer à la fenêtre d'édition du code SQL.
Bon, parlons des caractéristiques des procédures stockées d'Access.
Mon sentiment actuel est que la requête Access est un wrapper pour l'instruction SQL, peut-être avec une certaine optimisation telle que la précompilation. Nous ne pouvons pas utiliser plusieurs opérations, transactions, jugements logiques, boucles, etc. comme l'écriture de procédures stockées SQL Server...
Mais l'objectif principal de l'utilisation des procédures stockées Access est d'utiliser des requêtes fournies par des paramètres supplémentaires. Grâce aux procédures stockées, nous n'avons plus à faire face aux divers problèmes rencontrés lors de l'épissage des valeurs des paramètres dans des chaînes d'instructions SQL, telles que :
Code:
Faible SQL
sql = SELECT * FROM Utilisateurs WHERE Nom d'utilisateur = ' & Nom d'utilisateur & '
Dans le code ci-dessus, si la variable chaîne userName contient des « guillemets simples », une erreur sera signalée. Nous devons convertir manuellement :
Code:
Faible SQL
sql = SELECT * FROM Users WHERE UserName = ' & Replace(userName, ', '') & ' ' est converti en deux guillemets simples consécutifs
En utilisant une requête avec des paramètres, notre instruction SQL peut être écrite comme :
Code:
Faible SQL
sql = SELECT * FROM Utilisateurs WHERE UserName = @userName
Il suffit ensuite de transmettre la valeur du paramètre @userName en utilisant la propriété Parameter de l'objet Command, ce qui est très pratique et intuitif.
Code:
Avec cmd
'Créer un objet paramètre
.Parameters.Append .CreateParameter (@userName)
'Spécifiez les valeurs pour chaque paramètre
.Paramètres (@nomutilisateur) = nomutilisateur
Terminer par
Ici, nous expliquons également l’utilisation des paramètres dans les procédures stockées Access. Contrairement aux procédures stockées de SQL Server, qui utilisent des variables @ pour spécifier des paramètres, puis transmettent des objets paramètres portant le même nom, les paramètres dans Access sont identifiés par ordre plutôt que par nom. Il n'est pas nécessaire de spécifier un nom pour les paramètres transmis. Vous pouvez les nommer de manière désinvolte. Les noms des paramètres dans SQL peuvent également être nommés de manière informelle. Tant que les valeurs des paramètres sont transmises, elles doivent être spécifiées dans l'ordre. dans lequel les paramètres apparaissent dans l'instruction SQL. Habituellement, nous utilisons la méthode Execute de l'objet Command et transmettons directement le tableau de valeurs de paramètre pour exécuter ~
Code:
cmd.Execute, Array (nom d'utilisateur)
Pour un autre exemple, l’une de vos procédures stockées Access est écrite comme ceci :
Code:
sélectionnez * parmi les utilisateurs où UserName = p_UserName et BookTitle = p_bookTitle
Vous pouvez simplement le faire de cette façon, en passant un tableau de valeurs de paramètres, mais dans le bon ordre :
Code:
cmd.Execute, Array (nom d'utilisateur, titre du livre)
OK, regardons les deux requêtes utilisées dans notre exemple, l'une consiste à écrire des données. Après avoir écrit l'instruction SQL, enregistrez-la et nommez-la.
Un autre code de procédure stockée qui lit les données.
(2) Utilisation de procédures stockées
Nous pouvons ensuite appeler ces procédures stockées dans le programme ASP.
Ici, vous pouvez voir pourquoi j'ai dit que la requête dans Access est sa procédure stockée - la propriété CommandType de notre objet Command est définie sur 4, ce qui correspond à Stored Proc !
donc...
Le code suivant est très simple :
Code:
<%
Option explicite
Dim s
Randomiser
s = Rnd * 100
Dim conn, cmd
Définir conn = Server.CreateObject (ADODB.Connection)
Définir cmd = Server.CreateObject (ADODB.Command)
conn.Open Provider=Microsoft.Jet.OLEDB.4.0 ; Source de données= & Server.MapPath(sp.mdb)
Avec cmd
.ActiveConnection = connexion
.CommandType = &H0004 'Procédure stockée
.CommandText = AddNewData
Terminer par
cmd.Execute, Array(CStr(Now()), CSng(s))
Avec cmd
.ActiveConnection = connexion
.CommandType = &H0004 'Procédure stockée
.CommandText = GetData
Terminer par
Dim résultatRS, resultArray
Définir resultRS = cmd.Execute(, Null)
Si ce n'est pas le cas resultRS.EOF Alors
resultArray = resultRS.GetRows()
Fin si
Définir le résultatRS = Rien
Définir cmd = Rien
conn.Fermer
Définir la connexion = Rien
Réponse.Écrire <ul>
Faible je
Pour i = 0 Vers UBound (resultArray, 2)
Réponse.Write <li> & resultArray(0, i)
Réponse.Write & resultArray(1, i)
Réponse.Write & resultArray(2, i)
Réponse.Ecrire </li>
Suivant
Réponse.Ecrire </ul>
%>