Aide - Recherche - Membres - Calendrier
Version complète : arcanes d'ouverture des tables
Les Forums de PalmAttitude.org > GENERAL PalmOS > Développement sous PalmOS
Palmidem
Bonjour,
je suppute rolleyes.gif des astuces dans l'utilisation des hbModeOpenExisting ou OpenAlways / createalways .. sans parler des hbModeRead/Write. Plusiueurs instances peuvent-elles être ouvertes en même temps selon le mode (ReadOnly) ?
Avec mes grid_change qui impliquent des Pop_change, j'ai du mal à suivre les shared violation // table non opened icon_evil.gif
y'a une astuce standard, plutot que je cherche des hueres une solution qui sera de toute façon moins bonne ? icon_question.gif fermer systématiquement en sortie pour réouvrir systématiquement ? affecter un nom de variable différent pour chaque procédure ? toujours tout laisser ouvert ? mettre en by pass par un "On error goto suite" et "suite:" juste sous la ligne d'ouverture ( au fait, y'a pas de "resume next" ?)
Merci
Payalba
Tu travailles avec hB++ ?

Je ne comprends pas vraiement le problème mais si c'est un problème de table ouverte peut être que l'ouverture ne c'est pas faite et tu trapes mal l'erreur ou peut être utilises tu une variable local qui est détruite en sortie de procédure, ....

Bref les causes peuvent être multiples. Peux tu donner un extrait de ton code ? ou mieux détailler ton problème ?
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.
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 ?
Palmidem
CITATION(Payalba)
Tu travailles avec hB++ ?
(...) si c'est un problème de table ouverte peut être que l'ouverture ne c'est pas faite et tu trapes mal l'erreur ou peut être utilises tu une variable locale qui est détruite en sortie de procédure, .... Peux tu donner un extrait de ton code ? ou mieux détailler ton problème ?

Pardon Payalba, je n'avais pas répondu à ta demande de précision, car le nez dans le guidon.
Il s'agit d'un utilitaire de gestion d'activités basé sur l'agenda, pour lequel Poolpy m'a passé des exemples et a développé forms et codes.
Pour ma part, je l'ai adapté à mes besoins, qui je pense sont génériques (catégorie, client, projet, tache, activité, déplacement, frais, ... ), pour un re-traitement des lignes importées de l'agenda. En fait, je voyais mal en pratique (temps de saisie, poids des bases) comment tout écrire d'emblée dans l'agenda (après différents tests dont docs de l'agenda avec Teikei).
Les problèmes de tables ont été résolus ... par une simplification, comme le plus souvent.
Merci de ton aide. Je viens par ailleurs de m'inscrire sur le forum HB++
poolpy
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.
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2008 Invision Power Services, Inc.