CITATION(Palmidem)
CITATION(poolpy)
Salut,
L'approche classique, c'est de garder par form une instance en readOnly, éventuellement filtrée (OpenRecordset au lieu de OpenTable) qui sera utilisée pour l'affichage des données (genre la grid) ; puis de créer des instances en local (readWrite) chaque fois qu'une donnée devra être modifiée.
Slt Poolpy,
voilà, je comprends mieux : le sharing viloation ne survient que si tentative d'ouverture d'une 2e instance en x/write, mais pas si on reste ouvert en RO.
Si ouvert en RO, la fermeture de la table ou recordSet est un effet de style ou une obligation ? Par ailleurs, cette instance RO s'enrichit-elle des nouveauté inscrites par une instance RW intercurrente ?
Ca parait surement bête, mais ...
Merci
Au fait, Poolpy, as-tu reçu mes MP ?
Salut,
J'ai reçu tes MP et répondu, mais je réponds quand même ici si ça peut servir à certains :
- On peut ouvrir simultanément autant d'instances qu'on veut en lecture seule (hbModeReadOnly), mais une seule instance en écriture (hbModeWrite, hbModeReadWrite) ne peut être présente à la fois.
- Pour la fermeture, la table est automatiquement fermée lorsque l'instance qui l'encapsule est mise à la poubelle. Cela se produit évidement lorsqu'on quitte une procédure / fonction dont c'est une variable locale, ou bien quand la form ou la class qui possède une référence vers l'instance est détruite (en clair, quand tu déclares une table dans une form, la table est détruite quand la form qui la contient est détruite). Mais comme la destruction d'un objet est souvent retardée (à cause du mécanisme de ramassage des miettes, ou garbage collection, qui ne se fait que périodiquement ou en cas de saturation mémoire), il est conseillé de fermer manuellement la table dès que l'on n'en a plus besoin.
- Si une table est ouverte en lecture et en écriture, la version ouverte en lecture incorporera les enregistrements écrits simultanément.