Discussion :

[jeanyvesvey]

Bonjour à vous tous,

Pour ce premier post et apres avoir pris connaissance des messages recu dans ce sens et n'ayant trouvé aucune réponse voici ma question

J'ai sur un serveur des tables access appelés par 5 interfaces sur des postes client

version access 2002 pour les tables et les interfaces

Lorsque l'interface 1 se connecte aux tables création du fichier .ldb

Vérification avec le logiciel LDB Viewer qui permet de lire le ldb je vois effectivement que Interface 1 est connectée

Interface 2 se connecte disparition dans le LDB VIEWER de tous les utilisateurs mais pas de message me disant que personne n'est connecté puisque le LDB existe toujours

Interface 1 se déconnecte disparition du .ldb bien que Interface 2 soit toujours connectée (LDB VIEWER Complétement perdu !!! il ne sait quoi afficher)

J'ai fait des tests en local pour essayer de recréer le problème

2 postes contenant les interfaces et un poste disposant des tables le tout sur un réseau de poste à poste sans vraiment "1 serveur proprement dit"

et la aucun problème le .ldb ne se ferme que quand plus personne n'est connecté

ALORS C'EST QUOI CE PROBLEME !!!!!!!!

veuillez excuser mon enervement mais ça me seme une panique dans toutes les tables ça fait même exploser mes relations enfin bref

Tout ça est logique puisque une interface ou plusieurs interfaces peuvent modifier les données sans le controle du .ldb

Voili voilo le seveur est sur windows serveur 2003
avec Small business serveur

Je ne sais pas si j'ai posté dans la bonne rubrique mais je ne doute pas qu'un développeur sur access a déja eu le même probleme

Un grand bonsoir de la Guadeloupe (ici il est 16 05) et merci pour toutes les réponses ou piste sque vous pourrez m'apporter

[=JBO=]

Bonjour à vous tous,

Bonjour La Guadeloupe,

J'ai sur un serveur des tables access appelés par 5 interfaces sur des postes client

Je traduis : tu as effectué un découpage type dorsal / frontal, et il y a potentiellement 5 utilisateurs simultanés pour ton application frontale.
Correct ?

ALORS C'EST QUOI CE MERDIER !!!!!!!!

veuillez excuser mon enervement mais ça me seme une panique dans toutes les tables ça fait même exploser mes relations enfin bref

Tout ça est logique puisque une interface ou plusieurs interfaces peuvent modifier les données sans le controle du .ldb

Je ne suis pas sûr de bien te comprendre:
« une interface ou plusieurs interfaces peuvent modifier les données sans le controle du .ldb »

Non, modifier des données implique la pose de verrous sur les données et le fichier des verrous est justement le LDB.

Je pense que tu devrais expliquer un peu plus le problème rencontré: message d'erreurs ? plantages ? etc.

Voili voilo le seveur est sur windows serveur 2003 avec Small business serveur

(1) Chaque PC dispose-t-il de sa propre copie de l'application frontale ? C'est indispensable.

(2) On signale aussi des soucis sur les serveurs de fichiers Windows concernant le paramétrage du verrouillage opportuniste (opportunistic lock) via le paramètre EnableOplocks dans la base de registre et qu'il vaut mieux interdire dans certaines situations.
Pour en savoir plus, je te laisse en tête à tête avec ton moteur de recherche préféré.

Et une piste de lecture quand même...
Opportunistic Locking and Read Caching on Microsoft Windows Networks
_

[jeanyvesvey]

Pour commencer un grand merci pour ta réponse JBO

Comme j’étais sur le c.. en voyant ce genre de chose possible je n’ai pas suffisamment expliqué ce qui se passe vraiment
1/
Je traduis : tu as effectué un découpage type dorsal / frontal, et il y a potentiellement 5 utilisateurs simultanés pour ton application frontale.
Correct ?

Oui c’est la procédure multi-utilisateur effectivement, donc 5 postes équipée ACCESS 2002 SP3 qui se connecte tout le temps aux tables ou application dorsale par réseau à un serveur Microsoft Server 2003 (Small business server). Occasionnellement des portables se connectent ils sont aussi équipés ACCESS 2002 SP3 même dorsale que les fixes (mais depuis les problèmes je ne les y autorise plus) donc 5 postes fixes avec l’appli dorsale. J’essayais de ne rien oublier pour être le plus clair possible car il est vrai à distance ce n’est jamais facile d’aider quelqu’un.

Depuis déjà 10 ans que j’ai développé cette applicatif (a l’origine en Access 97 et maintenant en ACCESS 2002) je n’avais jamais eu de probleme, je gere maintenant la maintenance du produit depuis la GUADELOUPE par web et terminal server et voilà que depuis le mois de juin j’ai tout un tas de problèmes (je précise que je ne suis pas en charge du réseau ni des mises à jour serveur des fois que !!!).

Donc depuis le mois de juin je galère, sauvegardes des tables (ou dorsale ??) tous les soirs, recompilation (re car j’en fait une en automatique a partir de n’importe qu’elle frontal si le ldb et fermé (vérif par code) et seulement si cela n’a pas été déjà fait 1 fois par jour (sauvegarde de la date du dernier lancement de la procédure de compilation)

Type de problèmes que je rencontre donc depuis le mois de juin

Relations 1 vers l’infini entre 2 tables qui disparaissent car la suppression en cascade ne s’est pas faite

Des enregistrements de type ####### ou signet non définit

Message de genre signets non défini

Vous ne pouvez modifier cet enregistrement parce………

Je précise que je n’ai procédé à aucune modification ni sur les frontales ni sur les dorsales avant que tout ne se mette en vrac

Donc à distance j’ai pris le contrôle de 2 frontales et du serveur et ce sur 3 postes différent en GWADA enfin à partir de chez moi

Je lance la première appli frontal elle fait ce qu’elle doit faire et ouvre un ldb sur le serveur (dorsal) Super c’est comme ca que c’est prévu. Je vérifie avec le programme LDBVIEWER et effectivement je trouve les références du poste connecté à l’appli dorsale tout cela me semble normal

Je lance une deuxième appli frontale, le ldb reste présent, je vérifie avec LDBVIEWER et là plus aucune coordonnée il ne voit plus personne mais il me dit pas que personne n’est connecté puisque le ldb existe toujours

Je ferme la première appli frontale (celle qui avait générer l’ouverture initiale du ldb) et la disparition du ldb alors que la 2ème appli est toujours ouverte c’est ca qui n’est pas normal d’ou je pense et vraisemblablement c’est problèmes dans les enregistrements des différentes tables

Donc apparemment Oui c’est ca !!
« une interface ou plusieurs interfaces peuvent modifier les données sans le controle du .ldb »



Non, modifier des données implique la pose de verrous sur les données et le fichier des verrous est justement le LDB. La je suis entièrement d’accord avec toi sinon ou va nous


(2) On signale aussi des soucis sur les serveurs de fichiers Windows concernant le paramétrage du verrouillage opportuniste (opportunistic lock) via le paramètre EnableOplocks dans la base de registre et qu'il vaut mieux interdire dans certaines situations.
Pour en savoir plus, je te laisse en tête à tête avec ton moteur de recherche préféré.

Merci pour le lien je vais faire marché mes petites cellules grises mais là vraiment je rame effectivement cela peut être un problème serveur car comme je te l’ai expliqué sur le premier post avec les mêmes frontales et la même dorsal chez moi en simple réseau aucun problème ou pani pwoblem comme on dit en créole

Si à lecture de mon complément d’information tu avais d’autres pistes à me proposer je t’en remercie par avance

Bonne nuit et encore merci

Enfin comme on dit l’informatique n’est pas une science exacte ni donnée

[Maxence HUBICHE]

Déplois les dorsales sur les postes, pas sur le serveur.

Ca parait quand même bizarre ton problème
Tu as essayé un compactage de ta base ?
Te fait-elle des erreur du genre : la base doit être réparée !

[argyronet]

Bonjour,

Quand tu écris :

je vérifie avec LDBVIEWER et là plus aucune coordonnée il ne voit plus personne mais il me dit pas que personne n’est connecté puisque le ldb existe toujours

est-ce cette version ?

Ca m'interesse de la savoir dans le sens où j'en suis l'auteur et s'il y a des bugs, autant les fixer.

Argy

[6ril25]

Bonjour,

Argyronet, au sujet de LDBViewer, ici (http://argyronet.developpez.com/down...ewer/index.htm

Superbe outil, j'ai pu le tester en local.

Mais, est-il utilisable sur access 97? en réseau?
En effet, il me donne une erreur: "erreur d'execution 9, Indice en dehors de la plage" quand je veux voir les utilisateurs connectés.

Une idée??

[argyronet]

Mais, est-il utilisable sur access 97? en réseau?
En effet, il me donne une erreur: "erreur d'execution 9, Indice en dehors de la plage" quand je veux voir les utilisateurs connectés.

Sur 97 en réseau ? Je pense que oui
Essaye plutôt en attendant la version précédente.
Merci de cette remontée, je vais regarder ça.

Argy

[6ril25]

Salut,

Pour être plus précis, il fonctionne bien quand aucun utilisateur n'est sur la Bdd, mais si ce n'est pas le cas, ERREUR...
Si tu as une idée, fais moi signe