Utiliser le modèle ADOX avec Visual Basic

Dans ce modèle, il y a une certaine redondance. Dans le cas d'Access, une requête non paramétrée renvoyant des enregistrements est considérée comme une table de type « VIEW » (vues). Une telle requête apparaîtra donc comme membre de la collection « Table » (un peu différente des autres tables) et comme membres de la collection « Views », mais pas comme membre de la collection procédure.

Attention, dans Access il faut considérer une procédure comme une requête paramétrée ou une requête ne renvoyant pas d'enregistrement (Requête action par exemple) ; n'attendez pas de récupérer des procédures VBA dans cette collection.

Cette notion de propriété est très importante. En effet seul le propriétaire d'un objet peut faire certaines modifications sur celui-ci et attribuer les droits sur ces objets. Par défaut, le propriétaire d'un objet est son créateur. Cela implique deux choses :

Ne pas laisser aux utilisateurs le droit de créer des objets dans vos bases sans un contrôle, car vous n'auriez pas de droit de modifications sur ces objets sans en reprendre la propriété.

Gérer strictement les droits sur la base.

Nous y reviendrons plus en détail lorsque nous aborderons la sécurité.

Lorsque l'on crée des objets, ils ne sont reliés à aucun catalogue. Dès lors, comme ils ne connaissent pas leurs fournisseurs, il n'est pas possible de valoriser leurs propriétés. On définit donc la propriété ParentCatalog d'un objet dès que l'on souhaite valoriser ses propriétés. Ceci pourtant dissimule un problème d'un fort beau gabarit ma foi. Outre le fournisseur, le catalogue transmet aussi ses droits de propriétaire. Si on n'y prend pas garde, il se peut que l'objet se retrouve ayant des droits non souhaités.