Discussion :

[IADJOFOGUE]

Bonjour,
Supposons que je sois dans une application Client/Serveur qui utilise le contrôle Winsock, où seul le serveur accède à la base de données. Peut-on considérer que le nombre de clients correspond au nombre de connexions à la base de donnée ?
Lorsque je me mets dans le cas où le serveur reçoit des paramètres de chaque client, puis se charge des requêtes en direction de la base de données, est-il judicieux d'utiliser une base de données Access ou bien est-il préférable de choisir un vrai SGDB (selon le budget : Firebird, Postgresql, etc...).
Le nombre de client pourrait monter à 50.

Merci pour vos contributions.

Meilleures salutations

[Delbeke]

Dans ce cas de figure, un seul programme accède à la base de données. Une base access conviendrait parfaitement. par contre, bonjour la programmation du programme serveur.Cà va pas etre facile à mettre au point, mais c'est possible.

[IADJOFOGUE]

donc le plus simple serait de laisser chaque client se connecter à la base pour faire sa requête. Et par voie de consséquence, une base Access ne conviendrait plus !

[Delbeke]

Access peux le faire, mais avec 50 utilisateurs connectés simultanement, ca va ramer un peu

en fait avec access, c'est comme si 50 postes accèdaient au meme fichier situé sur un serveur.

avec une base client/serveur, c'est un seul programme qui accède a base, extrait/ajoute/modifie les infos de la base et qui transmet les resultats aux demandeurs. en fait, excatement ce que tu envisageais de faire

[IADJOFOGUE]

EN fait, j'avais déjà une application où un dizaine de clients se connectent chacun à la base de données Access sur le serveur. mais le probleme que j'ai rencontré est celui de la corruption très fréquente de la BD. or il n'y a pas moyen de récupérer la DB Access corrompue lorsqu'elle est protégée par un mot de passe (Indispensable). c'est ce qui me fait envisager les deux options suivante :
1- Continuer dans la meme logique en changeant de DB (gratuite de préférence)
2- Entrer dans la logique du Client/Serveur en gardant Access.
Je suppose que dans le second cas, l'accès étant unique, il n'y aura plus ou presque plus des problèmes de corruption.

[Delbeke]

sais tu ce qui provoquait le crash de la base ? j'ai personellment beaucoup d'applis qui utilisent access en multiutilisateurs et n'ai pas ce probleme.

[IADJOFOGUE]

je crois que c'est essentiellement lié à des arrêts brusques des postes client et/ou la qualité du réseaux.

[Sharkus]

Bonjour,
J'ai également une application client serveur développé en VB6 qui accède à une base Access situé sur un des postes.

Je rencontre le même problème récurent de perte de données et de corruption de la base quand plusieurs utilisateurs se connectent chacun à la base de données.

Après réparation de la base, il y a pertes de relations ainsi que de données.

Je ne parviens pas à identifier le problème ! Y aurait-il d'autres cas qui ferraient crasher la base que des problèmes de réseau ou d'arrêt brusque de postes clients ?

A chaque fermeture de l'appli client, je réalise une copie de sauvagarde de la base sur le poste local.

PS: désolé si je ne suis pas dans la bonne section.

[Phifi]

sais tu ce qui provoquait le crash de la base ? j'ai personellment beaucoup d'applis qui utilisent access en multiutilisateurs et n'ai pas ce probleme.

Tu inclus les procédures de compactages/réparation de bases (DAO) dans tes applis Delbeke ?

La base .mdb est très sensible aux micro-coupures réseau ou autres arrêts intempestifs et se corrompt facilement (tout comme elle se répare), en tout cas de ce que j'ai pu connaître (avec un accès DAO cependant). Je ne les utilise plus que comme des spools d'impression (en local uniquement).

[nabil]

j'ai vecu un tel problème ca fait logtemps et si mes souvenirs sont bonnes je l'ai résolu ainsi:
1- j'utilise une BD sur le serveur
2- j'utilise une BD temporaire chez le client
3- je fais le transfert de donnée entre les deux bases aprés un test de connexion réseau sinon les données reste sauvegardé en local.
4- j'effectue des opération de compatage et réparation à chaque fermeture de la base.

D'ou la BD ne cracherai plus.

[Sharkus]

De mon côté je réalise bien une réparation/compactage de la Base a chaque ouverture de l'appli mais elle ne peut se faire uniquement dans le cas ou aucune appli n'accède à la base.

Une des solutions pourrait être de vérifier la connexion réseau avant chaque tentative d'accès à la base si j'ai bien compris. Ca fait un paquet d'accès réseau tout ça !

D'autres options ?

J'ai pu lire au support microsoft http://support.microsoft.com/kb/300216/ que si la base était sur un réseau avec des clients 98 et Xp ou 2000 et que la base est sur un poste 98 alors il peut y avoir des problèmes !

[Delbeke]

Tu inclus les procédures de compactages/réparation de bases (DAO) dans tes applis Delbeke ?

vi,vi , mais ca sert vraiement tres rarement

[Pierre Fauconnier]

Bonsoir

Bonjour,
J'ai également une application client serveur développé en VB6 qui accède à une base Access situé sur un des postes.

Attention. Il n'y a aucune possibilité de travailler en client/serveur avec Access.

Il y a, tout au plus, moyen de partager une base de données Access, mais ce n'est pas du tout comparable à un système Client/Serveur.

Avec Access, c'est chaque poste client qui fait tout le travail, et il n'y a aucun serveur de données.

[Delbeke]

En fait , il y a une technique. Utiliser une base access qui sert de relais. La veritable base de données etant une base client /serveur et les tables de la base Access n'etant que des tables liées.
C'est batard, mais ca fonctionne.