Bonjour,
C'est la premi=E8re fois que je viens ici, je ne sais pas si=20
vous pourrez me r=E9pondre.
Dans notre soci=E9t=E9 nous avons une base de donn=E9e avec un=20
formulaire pour saisir des nouvelles donn=E9es.
Lorsque sur un pote on saisie des donn=E9es et quelqu'un sur=20
un autre poste ouvre sa base de donn=E9es, sur le poste ou=20
l'on saisie les champs apparaissent avec #supprim=E9 et le=20
plus dramatique c'est que les donn=E9es ont vraiment=20
disparues.
Ce probl=E8me vient surtout sur les sous-formulaires.
Est-ce que quelqu'un sait pourquoi?
Line
Bonjour Pierre, Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses. Line
-----Message d'origine----- re,
"Line" Je reprend, je me demande si le problème n'est pas provoqué par la liaison entre les bases frontales et la base dorsale.
pas si tout est bien en place...
Car comme je le disais sur mon 2ème envoi, il y a suppression uniquement si lors de la saisie sur un poste quequ'un ouvre sa base de données sur un autre poste. J'avais pour la liaison au tables le module 'modActualiserAttachesTables' repris de l'exemple que donne Microsoft, je viens d'essayer 'Tables Attachées' que j'ai trouvé dans http://users.skynet.be/accesshome/tables.htm#Links, le problème persiste.
L'actualisation des attaches ne se fait (normalement) que lorsque la base frontale ou dorsale à été déplacée. Ce qui ne devrait pas être le cas bien souvent, en principe!
Sinon, ton problème n'est pas commun et même bizarre s'il n'y à pas de "manipulation" des données par du code ou événement qui serait non détecté...
Bonjour Pierre,
Je suis passée dans le magasin d'informatique où j'achete
tous mes programmes et par hasard j'ai discuté avec un
informaticien qui développe des programmes dédiés pour les
entreprises.
Je lui ai reporté mon problème et la solution qu'il
préconise est de créer une table temporaire en local et
décharger sur la table principale, cela ressemble comme
deux gouttes d'eaux à la solution du 18 frévrier, indiquée
par Luis.
En me disant que de toutes façon Access était tellement
capricieux qu'une sécurité valait mieux qu'une.
Qu'est-ce que tu en penses.
Line
-----Message d'origine-----
re,
"Line"
Je reprend, je me demande si le problème n'est pas
provoqué par la liaison entre les bases frontales et la
base dorsale.
pas si tout est bien en place...
Car comme je le disais sur mon 2ème envoi, il y a
suppression uniquement si lors de la saisie sur un poste
quequ'un ouvre sa base de données sur un autre poste.
J'avais pour la liaison au tables le
module 'modActualiserAttachesTables' repris de
l'exemple que donne Microsoft, je viens d'essayer 'Tables
Attachées' que j'ai trouvé dans
http://users.skynet.be/accesshome/tables.htm#Links, le
problème persiste.
L'actualisation des attaches ne se fait (normalement)
que lorsque la base frontale ou dorsale à été déplacée.
Ce qui ne devrait pas être le cas bien souvent, en
principe!
Sinon, ton problème n'est pas commun et même bizarre
s'il n'y à pas de "manipulation" des données par du code
ou événement qui serait non détecté...
Bonjour Pierre, Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses. Line
-----Message d'origine----- re,
"Line" Je reprend, je me demande si le problème n'est pas provoqué par la liaison entre les bases frontales et la base dorsale.
pas si tout est bien en place...
Car comme je le disais sur mon 2ème envoi, il y a suppression uniquement si lors de la saisie sur un poste quequ'un ouvre sa base de données sur un autre poste. J'avais pour la liaison au tables le module 'modActualiserAttachesTables' repris de l'exemple que donne Microsoft, je viens d'essayer 'Tables Attachées' que j'ai trouvé dans http://users.skynet.be/accesshome/tables.htm#Links, le problème persiste.
L'actualisation des attaches ne se fait (normalement) que lorsque la base frontale ou dorsale à été déplacée. Ce qui ne devrait pas être le cas bien souvent, en principe!
Sinon, ton problème n'est pas commun et même bizarre s'il n'y à pas de "manipulation" des données par du code ou événement qui serait non détecté...
"Line" Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se saurait...
Access (plutôt son moteur JET) est serveur de fichiers, d'accord. Mais la limite est plutôt du coté nombre d'accès et la sécurité des données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et ainsi augmenter le temps de réponse, mais, sur des données non partagées (ou très peu) comme la tables des localités et autres données du même genre.
Cela est donc difficilement praticable pour des donnés partagées. Et je ne parle même pas de la mise en pratique, car il faudra bien synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
"Line"
Je suis passée dans le magasin d'informatique où j'achete
tous mes programmes et par hasard j'ai discuté avec un
informaticien qui développe des programmes dédiés pour les
entreprises.
Je lui ai reporté mon problème et la solution qu'il
préconise est de créer une table temporaire en local et
décharger sur la table principale, cela ressemble comme
deux gouttes d'eaux à la solution du 18 frévrier, indiquée
par Luis.
En me disant que de toutes façon Access était tellement
capricieux qu'une sécurité valait mieux qu'une.
Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se saurait...
Access (plutôt son moteur JET) est serveur de fichiers, d'accord.
Mais la limite est plutôt du coté nombre d'accès et la sécurité des
données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et ainsi
augmenter le temps de réponse, mais, sur des données non
partagées (ou très peu) comme la tables des localités
et autres données du même genre.
Cela est donc difficilement praticable pour des donnés partagées.
Et je ne parle même pas de la mise en pratique, car il faudra bien
synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
"Line" Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se saurait...
Access (plutôt son moteur JET) est serveur de fichiers, d'accord. Mais la limite est plutôt du coté nombre d'accès et la sécurité des données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et ainsi augmenter le temps de réponse, mais, sur des données non partagées (ou très peu) comme la tables des localités et autres données du même genre.
Cela est donc difficilement praticable pour des donnés partagées. Et je ne parle même pas de la mise en pratique, car il faudra bien synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
Bonjour, Je vais encore essayer de refaire les formulaires depuis le début pour voir s'il n'y a pas un problème caché, ou que je ne détecte pas. Je te remercie pour tout le temps que tu as passé à m'aider. Line
-----Message d'origine----- Salut,
"Line" Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se saurait...
Access (plutôt son moteur JET) est serveur de fichiers, d'accord.
Mais la limite est plutôt du coté nombre d'accès et la sécurité des
données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et ainsi
augmenter le temps de réponse, mais, sur des données non partagées (ou très peu) comme la tables des localités et autres données du même genre.
Cela est donc difficilement praticable pour des donnés partagées.
Et je ne parle même pas de la mise en pratique, car il faudra bien
synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
Bonjour,
Je vais encore essayer de refaire les formulaires depuis
le début pour voir s'il n'y a pas un problème caché, ou
que je ne détecte pas.
Je te remercie pour tout le temps que tu as passé à
m'aider.
Line
-----Message d'origine-----
Salut,
"Line"
Je suis passée dans le magasin d'informatique où j'achete
tous mes programmes et par hasard j'ai discuté avec un
informaticien qui développe des programmes dédiés pour les
entreprises.
Je lui ai reporté mon problème et la solution qu'il
préconise est de créer une table temporaire en local et
décharger sur la table principale, cela ressemble comme
deux gouttes d'eaux à la solution du 18 frévrier, indiquée
par Luis.
En me disant que de toutes façon Access était tellement
capricieux qu'une sécurité valait mieux qu'une.
Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se
saurait...
Access (plutôt son moteur JET) est serveur de fichiers,
d'accord.
Mais la limite est plutôt du coté nombre d'accès et la
sécurité des
données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et
ainsi
augmenter le temps de réponse, mais, sur des données non
partagées (ou très peu) comme la tables des localités
et autres données du même genre.
Cela est donc difficilement praticable pour des donnés
partagées.
Et je ne parle même pas de la mise en pratique, car il
faudra bien
synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
Bonjour, Je vais encore essayer de refaire les formulaires depuis le début pour voir s'il n'y a pas un problème caché, ou que je ne détecte pas. Je te remercie pour tout le temps que tu as passé à m'aider. Line
-----Message d'origine----- Salut,
"Line" Je suis passée dans le magasin d'informatique où j'achete tous mes programmes et par hasard j'ai discuté avec un informaticien qui développe des programmes dédiés pour les entreprises. Je lui ai reporté mon problème et la solution qu'il préconise est de créer une table temporaire en local et décharger sur la table principale, cela ressemble comme deux gouttes d'eaux à la solution du 18 frévrier, indiquée par Luis. En me disant que de toutes façon Access était tellement capricieux qu'une sécurité valait mieux qu'une. Qu'est-ce que tu en penses.
Si cette méthode serait courante et nécessaire, cela se saurait...
Access (plutôt son moteur JET) est serveur de fichiers, d'accord.
Mais la limite est plutôt du coté nombre d'accès et la sécurité des
données, et ton problème ne semble pas provenir de là...
Une table locale est parfaite pour limité le transfert et ainsi
augmenter le temps de réponse, mais, sur des données non partagées (ou très peu) comme la tables des localités et autres données du même genre.
Cela est donc difficilement praticable pour des donnés partagées.
Et je ne parle même pas de la mise en pratique, car il faudra bien
synchroniser tout cela... après :-(
Désolé de ne pouvoir te donner de meilleure piste.
