Liste des propriétés d'une table

Bonjour à toutes et tous !

En tentant de lister les propriétés d'une table, j'obtiens l'erreur :

Citation:

---

Envoyé par Microsoft Visual Basic

L'objet est incorrect ou n'est plus défini.

---

Voici le code :

Code:

---

1 2 3 4 5 6

Sub ProprietesTable() Set T = CurrentDb.TableDefs("T_SYSTEME_LOCAL") For Each p In T.Properties Debug.Print p.Name & " ---> " & p.Value Next End Sub

---

L'erreur intervient à la ligne 3.
La liste des variables locales donne pour valeur de chacune d'entre elles la même erreur.

Evidemment, la table existe, n'est pas vide, est accessible... 8O

Dans l'attente de vos idées et vous en remerciant par avance, cordialement,
Eric.

eric13500

A froid sans contrôle

Code:

---

1 2 3 4 5 6 7

Sub ProprietesTable() Set Db = CurrentDb Set T = Db.TableDefs("T_SYSTEME_LOCAL") For Each p In T.Properties Debug.Print p.Name & " ---> " & p.Value Next End Sub

---

JimBoLion

Effectivement, ça fonctionne, mais je ne comprends pas pourquoi je ne peux pas le faire "à la volée"... 8O
A vrai dire, mon code initial était encore plus condensé :

Code:

---

1 2 3 4 5

Sub ProprietesTable() For Each p In CurrentDb.TableDefs("T_SYSTEME_LOCAL").Properties Debug.Print p.Name & " ---> " & p.Value Next End Sub

---

Je l'ai "délayé" pour tenter d'isoler l'erreur.

Rien n'est faux dans la syntaxe, et il me semblait que ce type d'instructions était résolu pas à pas...

Tu aurais une explication à ce phénomène étrange à mes yeux avant que je ne marque la discussion comme résolue ?

Merci en tout cas pour ton aide, et d'avance pour ton éventuel retour.
Cordialement,
Eric.

eric13500

Réponse ici :

http://warin.developpez.com/access/dao/?page=partie_4

JimBoLion

Merci pour ce lien.

J'ai relu ce que je pensais déjà connaître sans vraiment trouver de lien entre ma question et cette très intéressante introduction à DAO, jusqu'à ce que j'envisage que :

• dans la syntaxe directe, les objets appelés n'appartiennent pas à DAO...
• dans la déclaration explicite, les objets appartiennent implicitement à DAO

Donc, la déclaration explicite :

Code:

---

1 2 3 4 5

Dim Db as DAO.Database Dim T as DAO.Tabledef   Set Db = CurrentDb Set T = Db.TableDefs("T_TOTO")

---

Serait bien l'équivalent de la déclaration implicite :

Code:

---

1 2	Set Db = CurrentDb Set T = Db.TableDefs("T_TOTO")

---

mais pas dans le cadre d'un héritage direct :

Code:

---

Set T = CurrentDb.Tabledefs("T_TOTO")

---

Est-ce là ce qu'il fallait comprendre ? 8O

eric13500,

Effectivement, il y a nature à se poser quelques questions sur la manipulation des objets, et j'attends avec impatience l'avis de Tofalu à ce sujet.

Car l'hypothèse émise ne fonctionnerait donc pas dans ce cas précis, et pourtant les deux sont cohérentes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Dim oDb As DAO.Database Set oDb = CurrentDb Dim oRst As DAO.Recordset Dim Chaine_Sql As String ' Chaine_Sql = "SELECT T_Clients.* FROM T_Clients;" ' Set oRst = oDb.OpenRecordset(Chaine_Sql) ' If oRst.RecordCount = 0 Then oRst.Close Set oRst = Nothing Exit Function End If

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Dim oDb As DAO.Database Dim oRst As DAO.Recordset Dim Chaine_Sql As String ' Chaine_Sql = "SELECT T_Clients.* FROM T_Clients;" ' Set oRst = CurrentDb.OpenRecordset(Chaine_Sql) ' If oRst.RecordCount = 0 Then oRst.Close Set oRst = Nothing Exit Function End If

---

Donc je pense que dans le cadre des collections (ex. tabledefs) seule la déclaration explicite est tolérée alors qu'un accès aux méthodes (ex. Recordset) autorise les deux syntaxes.

J'ai appris à contourner certaines difficultés, je l'avoue bien modestement sans nécessairement chercher à comprendre toutes les subtilités liées à la manipulation des objets, méthodes ou propriétés. J'ai bien d'autres sujets, sur lesquels je me suis cogné la :mur:, et appris à accepter certaines choses

JimboLion

Chaque appel de Currentdb instancie un nouvel objet Database, donc le parcours de la collection n'est pas possible. On ne peut pas aller au suivant d'une chose constamment réinitialisée.

Si je demande à Paul de feuilleter toutes les pages du catalogue n°1 mais que je lui retire le catalogue dès qu'il a ouvert la première, on comprend aisément que "tourne la page" n'a plus aucun sens pour lui.

Ce qui pose un problème fatal ici c'est bien le fait de tenter d’accéder à quelque chose qui n'est pas fiable ou que "VBA" ne peut pas appréhender.

En revanche, les appels successifs de currentdb sans recourir à un objet Database déclaré, s'ils ne sont pas fatal sont largement déconseillés car ils empêchent le développeur de fermer proprement l'objet Database créé implicitement. Cette non fermeture et initialisation à Nothing est documentée par Microsoft (succinctement je l'accorde) et conduit à un accroissement significatif de la base de données et donc à un recours plus fréquent au compactage voire même à un risque accru de corruption du fichier.
C'est tordu, mais c'est comme ça.:lol:

eric13500,

Citation:

---

Effectivement, ça fonctionne, mais je ne comprends pas pourquoi je ne peux pas le faire "à la volée"...
A vrai dire, mon code initial était encore plus condensé :

---

La qualité du code ne se mesure pas en nombre de lignes, dans ce cas à quoi bon déclarer nos variables ou fermer nos objets :aie:

JimBoLion

Merci à tous les deux.

Tofalu, la profondeur de ta connaissance du sujet m'impressionnera toujours... Merci en tout cas d'être toujours disponible à nous faire mieux comprendre cet univers de programmation !
Et bravo pour la mise en situation avec Paul et son catalogue, ça va aider beaucoup de monde à comprendre ! :)

Citation:

---

Envoyé par Jimbolion

J'ai appris à contourner certaines difficultés, je l'avoue bien modestement sans nécessairement chercher à comprendre toutes les subtilités liées à la manipulation des objets, méthodes ou propriétés. J'ai bien d'autres sujets, sur lesquels je me suis cogné la tête, et appris à accepter certaines choses

---

Comme toi j'ai appris à faire certaines choses "parce que c'est comme ça", d'ailleurs, et tant que formateur, il m'arrive aussi de dire que, par manque de temps, "il faut juste accepter que c'est comme ça"... mais je dis aussi toujours que lorsqu'on comprend, on n'a pas besoin d'apprendre, et si je suis tout à fait capable d'accepter que "c'est comme ça", ça ne peut être que momentané et j'ai besoin tôt ou tard de savoir pourquoi...

Citation:

---

Envoyé par Jimbolion

La qualité du code ne se mesure pas en nombre de lignes, dans ce cas à quoi bon déclarer nos variables ou fermer nos objets

---

Bien qu'ayant lu sur ce forum qu'il n'était pas indispensable de fermer ses objets dans la mesure où ils l'étaient automatiquement en sortie de procédure, j'ai pour habitude de terminer chacune d'entre elle par un bloc "Sortie:" dans lequel je les passe tous à Nothing (et même que je le fais du plus imbriqué au plus grand conteneur parce que ça me parait plus logique !).

Concernant les déclarations en tête de procédure, fainéant que j'étais, j'ai commencé en n'en faisant aucune.
J'ai fini par comprendre qu'il était intéressant de déclarer, ne serait-ce que pour la lisibilité du code, et... "parce que c'est vachement mieux comme ça" ;)
Du coup, je me suis mis à tout déclarer. 8O
Puis, au fil des années et à force de pondre des lignes, j'ai fini par doser, et du coup ma stratégie est devenue la suivante : si je dois réutiliser, je déclare en tête, sinon à la volée. Dans le cas qui nous préoccupe, ce n'est pas moi qui réutilise, c'est la boucle, donc...

Ben maintenant, et grâce à cette discussion et à vos précieux conseils, je vais à nouveau réviser ma stratégie de déclarations !

Encore merci beaucoup à vous deux ! :hola: