Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97, Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm" se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm", mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97, Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm" se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm", mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97, Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm" se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm", mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le message
de news: 2C4BBD84-54BF-4FDB-B905-D02A15DB5775@microsoft.com...
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc. XP
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc. XP
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le message
de news: 2C4BBD84-54BF-4FDB-B905-D02A15DB5775@microsoft.com...
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc. XP
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base "Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes ouvrant
cette base avaient des version différentes de MSJet40.dll, la corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Re,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le
message
de news: 2C4BBD84-54BF-4FDB-B905-D02A15DB5775@microsoft.com...
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le message
de news: 5DD3282E-E643-4EA9-92F4-A6D06C0FF654@microsoft.com...
Re,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le
message
de news: 2C4BBD84-54BF-4FDB-B905-D02A15DB5775@microsoft.com...
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Des idées?
Je suis preneur de toute piste de recherche.
J'aimerais bien comprendre pourquoi cette base s'endommage régulièrement
alors que nous n'avions pas ce problème jusqu'au début de cette année.
Je suis en cours d'aménagement de mon application et préciserais bientôt si
l'installation de la base Pgm en local, et les bases données sur le serveur
résoud mon problème.
Cordialement.Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Des idées?
Je suis preneur de toute piste de recherche.
J'aimerais bien comprendre pourquoi cette base s'endommage régulièrement
alors que nous n'avions pas ce problème jusqu'au début de cette année.
Je suis en cours d'aménagement de mon application et préciserais bientôt si
l'installation de la base Pgm en local, et les bases données sur le serveur
résoud mon problème.
Cordialement.
Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le message
de news: 5DD3282E-E643-4EA9-92F4-A6D06C0FF654@microsoft.com...
Re,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.
Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" <XavierHUE@discussions.microsoft.com> a écrit dans le
message
de news: 2C4BBD84-54BF-4FDB-B905-D02A15DB5775@microsoft.com...
Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.
Bonjour,
Des idées?
Je suis preneur de toute piste de recherche.
J'aimerais bien comprendre pourquoi cette base s'endommage régulièrement
alors que nous n'avions pas ce problème jusqu'au début de cette année.
Je suis en cours d'aménagement de mon application et préciserais bientôt si
l'installation de la base Pgm en local, et les bases données sur le serveur
résoud mon problème.
Cordialement.Bonjour,
Le fait de séparer les données (serveur) de l'application frontale (sur
chaque poste) est à conseillé, bien entendu, mais
je ne pense pas que celà soit la cause (ni la solution) de ton problème.
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le message
de news:Re,Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
Dans mon cas, pas possible. Je ne suis pas maître de la gestion du parc.
XP
est déployer au fur et à mesure avec des machines neuves.D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
J'y avais pensé, mais...
Lors de mes recherches pour identifier la cause de ces anomalies, j'ai
développé un outils à exécuter sur chacun des postes à tester. Cet outil
démarre Access et charge notre application. Ce jusqu'à ce que je le
stoppe.
Je me retrouvais donc avec 25 à 30 sessions Access démarrées sur chaque
poste, donc autant de session de mon appli.
J'ai réalisé ce test en insérant petit à petit, les PC susceptibles de
provoquer l'erreur.
C'est à l'issu de ce test que nous avons remis nos machines à niveau,
après
voir constaté que MSJet40 était dans des versions obsolètes sur les PC
provoquant l'endommagement de la base.
A noter que l'appli chargé pour le test n'exécutait pas une seule ligne de
code, pas de macro autoexec, seulement un formulaire de démarrage sans
code.
Je ne pense pas que l'on puisse faire plus simple, donc, à priori pas de
défaut de programmation.
Nous allons nous orienter vers le schéma classique, base pgm installée en
local sur les postes, en prévoyant un déploiement automatique en cas de
mise
à jour.
Merci à tous pour vos indications.
Cordialement.Bonjour,
Pour éviter ce phénomène, il faut avant tout chercher à avoir un parc
homogéne concernant la version d'access (ou du run-time) et de windows.
D'autre part, il n'a pas à exclure que celà provienne d'un défaut de
programmation ou bien d'un défaut d'utilisation du produit.
Vérifiez par exemple les masque de saisie des utilisateurs, comment
accèdent
ils à la base ? Comment en sortent ils ???
--
Lucky_Team
http://www.access-developpement.com
"Xavier HUE" a écrit dans le
message
de news:Bonjour,
J'ai de nouveau, depuis quelques jours, le fameux message "format de
base
de
données non reconnu...".
J'ai été confronté au problème il y a quelques mois.
Voici mon environnement:
- Réseau d'entreprise 100BaseT
- Une dizaine d'utilisateurs équipés en Windows 2000 SP3, SP4, Windows
XP
SP1, et Access XP SP3
- Base "Pgm" sur un serveur Win 2000 SP4, tous les utilisateurs
accèdent
à
cette base, elle n'est pas installée en local sur leur poste
- Bases "data" sur le même serveur, dans le même dossier
Cette configuration est utilisée depuis 1998, au départ sous Access 97,
Win
95 et 2000, et aujourd'hui sous Access XP, Windows 2000 et XP.
Courant Mars, nous avons rencontré de grosses difficultés. La base
"Pgm"
se
trouvait régulièrement endommagée.
Nous avons eu jusqu'à une dizaine d'endommagements par jour durant la
période d'utilisation de cette application (quelques jours par mois).
Après moultes recherches et tests, j'ai constaté que si les postes
ouvrant
cette base avaient des version différentes de MSJet40.dll, la
corruption
de
la base était systématique.
Une chose étonnante, lorsque le message "format de base de données non
reconnu..." survient, c'est au moment de l'ouverture de la base "Pgm",
mais
tous les utilisateurs déjà connectés sur cette base peuvent continuer à
travailler??!!
Nous avons fait une mise à niveau de tous les postes (Win 2000 et XP)
courant Avril. Nous avions donc MSJet40.dll 4.0.8618.0.
Ce message est réapparu ce mois-ci.
Nous avons re-vérifier tous les PCs, et constaté que sur tous les
postes
Win
2000, MSJet40 est passé à une version ultérieure (4.00.9025.0).
Cette version a semble-t-il été installée avec le patch KB837001 du
09/05/2005.
Mes interrogations:
Que puis-je faire pour éviter l'endommagement de la base?
Me faut-il abosulument un environnement homogène (même version
Windows)?
En dehors de MSJet40.dll, y-a-t-il d'autres DLLs à surveiller?
Installer la base "Pgm" en local sur les PC des utilisateurs, avec des
versions Windows différentes (2000 et XP), et donc MSJet différent
peut-il
résoudre le problème?
Quid des mises à jour automatiques qui ne seront pas forcément
appliquées
sur tous les postes en même temps, et donc, risque de redécalage des
version
du MSJet40?
D'avance merci pour vos suggestions.
Cordialement.