X. L'objet Procedure▲
Cet objet peut représenter plusieurs choses selon les cas.
- Une requête Action
- Une requête paramétrée
- Une procédure stockée (n'existe pas dans Access)
En soi cet objet est très simple à utiliser puisqu'il ne s'agit que d'un objet Command ayant un nom dans la collection Procedures. Comme nous avons vu plus haut l'objet Command suffisamment en détail, nous allons nous pencher dans ce chapitre sur l'ajout ou la modification de l'objet Procedure.
X-A. Création d'un objet procédure▲
Elle se fait en général en utilisant la méthode Append de la collection Procedures de la forme
Catalog.Procedures.Append Name, objCommand
Où objCommand est un objet Command. Tout se fait donc dans la définition de l'objet Command.
Dans le cas d'une requête action, la création est facile puisque le texte de la commande est le code SQL. Mais dès lors qu'il y a utilisation de paramètres, il faut faire attention.
X-A-1. Pas d'objet Parameter▲
Nous avons vu que pour l'appel des procédures stockées ou des requêtes paramétrées, nous utilisions les objets Parameters de la commande. Lors de la création, cela n'est pas possible. La propriété CommandText de l'objet Command Doit contenir l'ensemble de la requête / procédure telle qu'elle est effectivement écrite dans le SGBD.
À part cela, la création d'un objet Procedure ne pose aucun problème.
Exemple▲
Dans la suite de mon exemple, je peux ajouter
Set
MaCommand =
New
ADODB.Command
MaCommand.CommandText
=
"PARAMETERS [QuelNom] TEXT(50);SELECT * FROM PremTable WHERE Nom = [QuelNom]"
Catalogue.Procedures.Append
"ParNom"
, MaCommand
Ce code ajoute une requête paramétrée nommée « ParNom » attendant le paramètre « QuelNom » de type texte.
Il est tout à fait possible de créer une requête action paramétrée. Par exemple
PARAMETERS
DateCib DateTime
, BancCib Text
(
255
)
;DELETE
*
FROM
tblAnomalie WHERE
NumBanc=
[BancCib]
AND
DatDimanche>=
[DateCib]
;
Est une requête valide.
Attention : Pour les paramètres, il faut bien préciser la taille dans le corps de la procédure. En effet, si j'avais écris PARAMETERS [QuelNom] TEXT, sans préciser une taille inférieure ou égale à 255 j'aurais créé un paramètre de type mémo au lieu de texte.(adLongVarWChar au lieu de adVarWChar). Ce genre d'erreur engendre des bugs très difficiles voir impossibles à retrouver pour les utilisateurs de vos bases de données.
X-B. Modification d'un objet Procedure▲
La modification de l'objet Procédure passe par la modification de l'objet Command sous-jacent. Donc en général on affecte à un objet Command l'objet Command de l'objet Procedure, on modifie le texte et on fait l'opération inverse. Par exemple :
Set
MaCommand =
Catalogue.Procedures
(
"ParNom"
).Command
MaCommand.CommandText
=
"PARAMETERS [QuelLocal] TEXT(255);SELECT * FROM DeuxTable WHERE Local = [QuelLocal]"
Set
Catalogue.Procedures
(
"ParNom"
).Command
=
MaCommand
« Mais alors, pourquoi ne pas écrire ? »
Catalogue.Procedures
(
"ParNom"
).Command.CommandText
=
"PARAMETERS [QuelLocal] TEXT(255);SELECT * FROM DeuxTable WHERE Local = [QuelLocal]"
La raison est la suivante :
Intrinsèquement, un objet Command est volatil, c'est-à-dire qu'il n'est pas lié à la base de données (a contrario des objets DAO QueryDefs). Si nous utilisions le code ci-dessus, la procédure se comporterait comme attendu au cours de la même session de programme, mais les modifications ne seraient pas enregistrées dans la base de données et ces modifications seraient perdues. C'est pourquoi il convient de réaffecter explicitement un objet Command à l'objet Procedure.