[Access] DB Instable

[lem01]

Bonjour,

Nous avons une application développée en Accesss, et qui utilise une base de données Access également.
Cette application est utilisée par une 20ène de personnes et devient instable (db crash, il faut reboot...).
J'ai lu que les DB access étaient connues pour être instables a partir d'un certain nombre d'utilisateurs, mais j'aurais aimé en savoir plus...

Egalement, la solution à laquelle je pensais était de passer le coté "database" vers Oracle et de garder l'application Access tel quel.(et y lier les tables vers oracle)

Qu'en pensez vous? L'application sera t-elle stabilisée ?
J'aimerais être certain d'ou provient cette instabilité avant d'entreprendre quoi que ce soit.
Merci

[loufab]

Bonjour,

Le fait d'ajouter un Xème personne ne peut causer d'instabilité. Pourquoi à la 20ème et pas à la 19ème ?

Il faut vérifier :

1. que le nouveau poste soit bien à jour (même version que les autres, Service Release et Service Pack)
2. qu'il n'y ai pas de coupure réseau (c'est souvent le cas) perte d'info due à un cablage défectueux, un hub trop chargé...
3. que l'utilisateur ne fasse pas n'importe quoi... éteindre la machine sans quitter les applications... utiliser directement les tables...

Cordialement,

Je suis parfaitement d'accord avec loufab.

Le problème provient très souvent d'une instabilité réseau.

Pour notre part, nous avons contourné ce problème comme suit :
- création d'un starter
- mise à disposition du starter aux utilisateur

Le starter copie le frontal dans le répertoire temp de l'utilisateur et démarre la copie. Ainsi, jamais de frontend corrompu à réparer.

Nous avons rarement eu avec ce système des bases dorsales endommagées, à l'exception de deux bases (sur plus de 100 bases) qui régulièrement voient apparaître des caractères chinois. Ces bases ont été développées n'importe comment par des néophytes et reprises par nos soins.

[lem01]

MErci pour vos réponses.
Il me semble pourtant avoir déja entendu plusieurs fois que les bases de données access ne sont pas "stable" a partir d'un certain moment...
Cela dépend il des acces concurrents a la DB, ou à la taille de la DB elle même, je n'en sais rien...

[lem01]

Microsoft Access is a desktop database, and not intended or designed for high-volume, multi-user use. Its performance under such conditions frequently becomes unpredictable and unstable.

Trouvé sur le site d'Adobe...
Je veux bien que Microsoft et Adobe ne sont pas forcément là pour s'envoyer des fleurs mais je doute que cette remarque d'Adobe soit sans fondement.

[loufab]

C'est le type de phrase qui ne veut rien dire.

A partir de combien de Mo une base est considérée comme gros volume ?
A partir de 2 utilisateurs une base est considérée comme multi-utilisateur !

Quand au comportement imprévisible et instable, je dirais que cela dépend du développeur, du service informatique (maintenance des postes à jour) et de l'infrastructure réseau (serveurs sous dimensionnés).

Maintenant il faut savoir choisir les bons outils pour les bons besoins. J'ai vu des bases fonctionner correctement avec plus de 30 utilisateurs et d'autres se vautrer lamentablement avec un seul.

Quand on commence à avoir des temps de réponse rédibitoire il faut penser à changer de moteur de base de données ou de réseau. Oracle c'est du lourd (financièrement et matériellement) si c'est pour 20 malheureux utilisateurs....

Regarde le débat pour ou contre ACCESS.

[Pepson]

Bonjour,

Envoyé par loufab

C'est le type de phrase qui ne veut rien dire.
Quand on commence à avoir des temps de réponse rédibitoire il faut penser à changer de moteur de base de données ou de réseau. .

Envoyé par jfc

- création d'un starter
- mise à disposition du starter aux utilisateur

Le starter copie le frontal dans le répertoire temp de l'utilisateur et démarre la copie. Ainsi, jamais de frontend corrompu à réparer.

Je ne me suis pas retrouve dans ses phrase la.
Cest quoi un starter?
comment on change un moteur de base de donne? la base reste toujours Access?

Merci de m'eclairer.

[loufab]

ACCESS est un EDI (Environnement de Developpement Intégré) comme Eclipse, Visual Studio et bien d'autres.

Il possède un moteur de base de données propriétaire qui s'appelle JET mais rien n'empêche d'en utiliser un autre :
SQL Server
MySQL
Oracle
DBase et autre Xbase
Paradox
...

On peut les choisir grace à ODBC (Open DataBase Connectivity).

Les discussions entre l'IHM (application ACCESS) et la base de données au travers d'ODBC se fait avec SQL (selon les règles de la base de données - souvent au standard ANSI 92) et ADO.
Voilà pour la petit histoire.

[lem01]

J'ai bien lu tous vos messages, mais ce qui m'étonne c'est que vous n'avez pas l'air d'aller dans le même sens que ce dont j'avais pu lire et entendre parler jusqu'à présent.

Le fait que ma DB plante, prouve, je pense, qu'il y a bien un problème de ce coté la, c'est pourquoi ma première question était de savoir si d'apres vous le fait de garder le layer application sous access mais passer le layer Database sous Oracle arrangerait la chose.

J'ai encore lu sur de nombreux post que Access n'était pas stable, pour des DB de taille (oui taille ça ne veut rien dire mais je parle de plusieurs centaines de milliers d'enregistrements), et pour des accès concurents important (20-30 users...)

Sans tenir compte du coup qu'implique une DB Oracle, je voudrais savoir si oui ça arrangerait mon problème. Si non, quelle pourrait être la solution?
Merci encore.

[loufab]

J'ai bien lu tous vos messages, mais ce qui m'étonne c'est que vous n'avez pas l'air d'aller dans le même sens que ce dont j'avais pu lire et entendre parler jusqu'à présent.

Personnellement je ne parle que par expérience et non par "on dit". Je ne vais surement par affirmer une contre-vérité pour faire plaisir à la masse, cette même masse qui bien souvent croit connaitre le produit.

Le fait que ma DB plante, prouve, je pense, qu'il y a bien un problème de ce coté la, c'est pourquoi ma première question était de savoir si d'apres vous le fait de garder le layer application sous access mais passer le layer Database sous Oracle arrangerait la chose.

Désolé de te contredire mais cela ne prouve rien. Seulement qu'il y a un problème. Pas obligatoirement interne à ACCESS. Cela peut venir du système, du réseau, des techniques utilisées pour le developpement (ça c'est super important surtout en multi-utilisateur) ou plus simplement d'un problème de paramètrage.
Si tu pense que tout est correct alors passe sous Oracle ou autre.

J'ai encore lu sur de nombreux post que Access n'était pas stable, pour des DB de taille (oui taille ça ne veut rien dire mais je parle de plusieurs centaines de milliers d'enregistrements), et pour des accès concurents important (20-30 users...)

Il ne faut pas oublié que Jet n'est pas un Client/Serveur mais un fichier/serveur, il dépend donc à 100% du paramétrage du serveur qui accueille le fichier dorsal. Si celui ci est sous dimensionné (comme le réseau) il ne peut qu'y avoir des problèmes.

Peux-tu nous en dire plus sur le type de serveur (nombre d'accès, serveur dédiés ou non...), le réseau, la version d'ACCESS, si les SP et SR sont bien à jour, l'architecture utilisées pour l'application, les méthodes d'accés aux tables...

Avant de classer catégoriquement un produit comme instable il faut avoir la certitude que c'est bien lui qui est en cause.

[lem01]

Je suis tout a fait d'accord avec toi!

C'est certainement la meilleur façon de procéder avant de pouvoir déterminer ce qui cause réellement le problème.

Tout de fois, l'application ACCESS fonctionne, les données sont correctement entrées dans la DB, et le process suit bien son court.
Donc même si l'application (développée sous access) n'est pas bien conçue (a vérifier), elle fonctionne correctement. Le seul hic c'est qu'après quelques années la DB plante.
Je ne suis pas expert dans le domaine, tu l'auras remarqué, mais que ça soit pcq la DB access dépend fortement de la configuration et du paramétrage du server l'hébergent ou que ça dépende de la version de Access ou quelques autres raisons, en remplaçant ce layer (server + DB) et en le remplaçant par qqchose dont on est certain de la robustesse, on éliminera ce problème d'instabilité qui, oui, n'est peut être pas lié a la DB elle meme mais a son environnement.

Je doute que le problème provienne de l'application elle même, mais si tu as une idée de comment vérifier cela ça serait bienvenue. De même vu le réseau en place je doute que cela provienne de la et encore, je ne pense pas que la DB planterait pour cette raison(serait ce le cas avec une autre DB)..?

Merci encore pour tes conseils!!

[loufab]

Le gros problème d'ACCESS est qu'il réagit très mal aux coupures et aux différences de versions de dll (notamment celle gérant le moteur Jet).

Vérifier qu'il y a suffisament d'accés sur le serveur.

Vérifier que le 20ème utilisateur à bien les mêmes versions que les autres. (SP -système- et SR -Office-).

Vérifier que les formulaires et états ne font pas d'accès directs aux tables mais passe par des requêtes.

Scinder l'application en 2 (interface sur chaque poste client, tables dans un ou plusieurs fichiers sur le serveur).

Faire régulièrement un compactage (1 fois par semaine).

... la liste n'est malheureusement pas exhaustive.

Si le problème est extérieur à Jet on risque de retrouver le problème avec d'autres BD. Sans compter les modifications qui devront (peut-être) être apporté à l'interface (requête, accès DAO -> ADODB).

Peux-tu me dire qu'elle version d'ACCESS vous utilisez ? Si la base est bien scindée en 2 ?