J'ai réalisé une application sous Access travaillant en réseau (mode partagé).
Les données (tables) sont placées sur le serveur alors que l'applicatif est
installé sur les postes de travail.
Je précise que l'ouverture de la DB est définie avec le verrouillage par
défaut sur "Enregistrement modifié" et l'option "Ouvrir avec enregistrements
verrouillés" cochée.
Les formulaires sont également paramétrés de la même manière (propriétés).
Lors de l'ajout d'un enregistrement via un formulaire, effectué sur un poste
simultanément avec une consultation des données, basée sur un autre
formulaire, par un autre utilisateur, l'application sur le premier poste se
"fige" et l'opérateur se voit contraint de la quitter "sauvagement".
Qui aurait une solution à ce problème particulier ?
Merci par avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
david
salut,
1° solution : la plus fiable Passe sous SQL serveur
2° solution : ettendre le verrouillage Sépares les opérations de lecture/ajout/suppression et modification en spécialisant tes formulaires. Modifies les propriétés correspondantes aux interdiction d'action. Utilise des instantanés dans tes formulaires de constultation (quitte à rafraîchir). Passer le verrouillage des formulaires de saisie à "total" (ou général suivant ta version).
3° solution : utilise des bases répliquées L'utilisation de base répliquées sur tes clients va largement augmenté la vitesse et te supprimer ce problème de partage (puisqu'il n'y en aurrai techniquement plus). Inconvénient, le système devient alors assynchrone (les modifications d'un poste ne sont répercutées sur les autres postes que lors de la mise à niveau de réplication).
4° solution : tables temporaires Créer des tables temporaires, sur chaque base appli (les clients). Ces tables seront à répercuter sur le serveur quand celui-ci le pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais elle n'est pas synchrone...
Bien, je pense avoir fait le tour... A+
salut,
1° solution : la plus fiable
Passe sous SQL serveur
2° solution : ettendre le verrouillage
Sépares les opérations de lecture/ajout/suppression et
modification en spécialisant tes formulaires. Modifies les
propriétés correspondantes aux interdiction d'action.
Utilise des instantanés dans tes formulaires de constultation
(quitte à rafraîchir).
Passer le verrouillage des formulaires de saisie à "total" (ou
général suivant ta version).
3° solution : utilise des bases répliquées
L'utilisation de base répliquées sur tes clients va largement
augmenté la vitesse et te supprimer ce problème de partage (puisqu'il
n'y en aurrai techniquement plus).
Inconvénient, le système devient alors assynchrone (les
modifications d'un poste ne sont répercutées sur les autres postes
que lors de la mise à niveau de réplication).
4° solution : tables temporaires
Créer des tables temporaires, sur chaque base appli (les clients).
Ces tables seront à répercuter sur le serveur quand celui-ci le
pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais
elle n'est pas synchrone...
1° solution : la plus fiable Passe sous SQL serveur
2° solution : ettendre le verrouillage Sépares les opérations de lecture/ajout/suppression et modification en spécialisant tes formulaires. Modifies les propriétés correspondantes aux interdiction d'action. Utilise des instantanés dans tes formulaires de constultation (quitte à rafraîchir). Passer le verrouillage des formulaires de saisie à "total" (ou général suivant ta version).
3° solution : utilise des bases répliquées L'utilisation de base répliquées sur tes clients va largement augmenté la vitesse et te supprimer ce problème de partage (puisqu'il n'y en aurrai techniquement plus). Inconvénient, le système devient alors assynchrone (les modifications d'un poste ne sont répercutées sur les autres postes que lors de la mise à niveau de réplication).
4° solution : tables temporaires Créer des tables temporaires, sur chaque base appli (les clients). Ces tables seront à répercuter sur le serveur quand celui-ci le pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais elle n'est pas synchrone...
Bien, je pense avoir fait le tour... A+
Ziegenhagen
Salut,
Merci pour les "tuyaux" que je vais m'empresser de tester. Cordialement. -- J-P. Ziegenhagen
salut,
1° solution : la plus fiable Passe sous SQL serveur
2° solution : ettendre le verrouillage Sépares les opérations de lecture/ajout/suppression et modification en spécialisant tes formulaires. Modifies les propriétés correspondantes aux interdiction d'action. Utilise des instantanés dans tes formulaires de constultation (quitte à rafraîchir). Passer le verrouillage des formulaires de saisie à "total" (ou général suivant ta version).
3° solution : utilise des bases répliquées L'utilisation de base répliquées sur tes clients va largement augmenté la vitesse et te supprimer ce problème de partage (puisqu'il n'y en aurrai techniquement plus). Inconvénient, le système devient alors assynchrone (les modifications d'un poste ne sont répercutées sur les autres postes que lors de la mise à niveau de réplication).
4° solution : tables temporaires Créer des tables temporaires, sur chaque base appli (les clients). Ces tables seront à répercuter sur le serveur quand celui-ci le pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais elle n'est pas synchrone...
Bien, je pense avoir fait le tour... A+
Salut,
Merci pour les "tuyaux" que je vais m'empresser de tester.
Cordialement.
--
J-P. Ziegenhagen
salut,
1° solution : la plus fiable
Passe sous SQL serveur
2° solution : ettendre le verrouillage
Sépares les opérations de lecture/ajout/suppression et
modification en spécialisant tes formulaires. Modifies les
propriétés correspondantes aux interdiction d'action.
Utilise des instantanés dans tes formulaires de constultation
(quitte à rafraîchir).
Passer le verrouillage des formulaires de saisie à "total" (ou
général suivant ta version).
3° solution : utilise des bases répliquées
L'utilisation de base répliquées sur tes clients va largement
augmenté la vitesse et te supprimer ce problème de partage (puisqu'il
n'y en aurrai techniquement plus).
Inconvénient, le système devient alors assynchrone (les
modifications d'un poste ne sont répercutées sur les autres postes
que lors de la mise à niveau de réplication).
4° solution : tables temporaires
Créer des tables temporaires, sur chaque base appli (les clients).
Ces tables seront à répercuter sur le serveur quand celui-ci le
pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais
elle n'est pas synchrone...
Merci pour les "tuyaux" que je vais m'empresser de tester. Cordialement. -- J-P. Ziegenhagen
salut,
1° solution : la plus fiable Passe sous SQL serveur
2° solution : ettendre le verrouillage Sépares les opérations de lecture/ajout/suppression et modification en spécialisant tes formulaires. Modifies les propriétés correspondantes aux interdiction d'action. Utilise des instantanés dans tes formulaires de constultation (quitte à rafraîchir). Passer le verrouillage des formulaires de saisie à "total" (ou général suivant ta version).
3° solution : utilise des bases répliquées L'utilisation de base répliquées sur tes clients va largement augmenté la vitesse et te supprimer ce problème de partage (puisqu'il n'y en aurrai techniquement plus). Inconvénient, le système devient alors assynchrone (les modifications d'un poste ne sont répercutées sur les autres postes que lors de la mise à niveau de réplication).
4° solution : tables temporaires Créer des tables temporaires, sur chaque base appli (les clients). Ces tables seront à répercuter sur le serveur quand celui-ci le pourra. Cette méthode, un peu sauvage, fonctionne parfaitement, mais elle n'est pas synchrone...
