Voila je m'explique:
 
-Une personne de ma boite ouvre la base situé sur le serveur depuis son PC
 
-Elle lance donc la requette a partir de son poste mais avec les doçnnées stocké sur le serveur.
 
Le probleme c que c'est horriblement long (30min)
 
On m'a demandé d'y remedier.
 
Donc est ce que si je remplace sont PIII600/128mo contre PIV2.4/512/granitybay ca va changé qq chose???
 
Ou alors est ce que le probleme c le réseaux entre les deux???
 
Le serveur est en RAID SCSI donc de tt facon il gratte fort.
 
Autre point important durant les calcul le reseaux ne semble pas utilisé en puissance  (inf 10%)
 
 
En fait dites moi ce que je dois changé comme matos pour que ca avance.
 
PS: ya des milliers de ligne a traités, c une facturation telephonique

Ah ah pour savoir si Quake 3 va plus vite a vec 128mo ou 1024mo tt le monde sait   , mais la je crois que j'ai posé une bonne question bine dure.  

1) C'est pas plutot a poster dans software & reseaux ca ?
2) Et si tu utilisais un VRAI SGBD  

MySQL par hasard ???
ca c'est de la base de données !!!!!!

 
1) je vois pas ou est le probleme software, notre base marche tres bien    
 
2)ben on la modifie tellement souvent que ca nous couterais des millions........

Ben visiblement ca marche pas si bien que ca
 
J'avouerai des le depart mon incompetence dans le domaine des BDD mais d'apres ce que j'avais compris (c'est pas tout recent), Access c'est vraiment pour les bases modestes. Des que t'as bcp de donnees et de requetes, ca suit plus et faut passer a des trucs plus gros en proprietaires (comme Oracle) ou libre (MySQL ou autres).  
 
C'est un peu comme Word, pour ecrire 5 pages ca va, mais pour 500 c'est la cata
 
Et c'est pas pour rien qu'une boite comme Oracle specialise dans la BDD marche si bien, c'est que c'est utile. Si access etait suffisant, on l'utiliserait plus.
 
Cela dit, je connais pas votre systeme et la taille de votre base, peut-etre qu'Access suffit. Donc mes propos sont a prendre de maniere generale

Regarde l'occupation CPU.
 
Si sur tes serveurs ou tes clients cai occupé à 100% les changer résoudra une partie du pb.
 
Sinon, change de soft.
 
(On avait fait des tests avec Lotus Notes et une appli partagée, on pouvait changer pour un réseau Mbit avec des serveurs P4 Xeon ça changeait rien au pb).

moi jdis que ca vient plutot du réseau ou du fait que la requete exige un gros calcul et que l'utilisation d'index aiderait beaucoup (et jcrois pas que access soit assez bien concu pour ca)
 
alors MySQL

Tout d'abord ACCESS ( en tout cas avec le moteur JET) ne sait pas fonctionner en réseau.
La seule solution c'est de partager le fichier sur le serveur et donc c'est la machine client qui fait tout le travail
 
Donc avec chaque fois que l'on fait un requete il faut transferer toutes les données du serveur vers la machine client ( pas toutes graces aux optimisations ). Donc suisvant le taille de des tables ça peut être très long surtout si le reseau est faiblar.
En suite tous les calculs sont effectué par la machine client, donc si la machine a 64Mo de ram ça va pas arranger la vitesse.
 
Enfin ACCESS n'aime pas les requete trop compliquées sur des tables trop grosses.
 

Mon avis :
 
Les requêtes sont exécutées par le serveur, donc la machine cliente n'a rien à voir avec ce problème de lenteur vu qu'elle est juste censée afficher ce que lui renvoie le serveur.
 
C'est donc le serveur qui doit en chier !
Pour le soulager il faut que t'optimises les requêtes et si elles le sont déjà, y'a plus qu'à changer le serveur.
 
Si ta base contient moults enregistrements, c'est étonnant qu'Access ait été choisi comme SGDB. Surtout en environement professionnel, ou l'on croise plus souvent du Oracle ou MySQL.
 
Mais ce n'est que mon avis ...

 
ACCESS ce n'est pas Oracle, il ne sait pas travailler en client serveur

Access -> poubelle
Suffit de migrer sous SQL Server 2000, ça va te prendre au moins... 10mins (enfin un peu plus vu la taille de la base)
Y'a rien à changer sur la machine client, mis à part rajouter un peu de ram

 
je dirais même plus :
ACCESS ce n'est pas Oracle, il ne sait pas travailler... tout court

Merci pour tt ces reponse mais comme vous l'aurez compris, on n'a pas les bessoin et surtout pas les moyen de passer sous Oracle.
 
 
Pour ce qui est du serveur j'avais oubliais de preciser que bien sure c le post client qui bosse, car le serveur en fait c juste un serveur de fichier ou est stocker la base (qui fait 800 mo, et 1600 mo les jours de facturation)
 
Pour ce qui est de l'utilisation CPU on est a 100, mais je ne pense pas que ce soit un probleme, car a mon avis il tourne dans la choucroute et passse plus de temps a atte,dre qu'autre chose.
 
La memoire elle est loin d'etre pleine. (70% je dirais)
 
Bon de tt facon je ramene la base ce soir a la maison et je vais faire des test demain en VNC avec le gars afin de voir si je gagne du temps en calculant avec ma becanne. (P4/DDR)

 
si le cpu est à 100%, il est pas en train de rien faire, faudrait déjà investiguer de ce côté-ci

 
une base access de cette taille

C vraimment trops gros????    

déjà une base access de 50mo ça explose & ça mets bcp de temps à s'ouvrir, alors là
migres sous SQL Server

La, je suis etonné.  
 
Certes, ACCESS n'est pas la panacée en matière de moteur de SGBD
 
Mais pour arriver a une requête de 30 minutes, même en réseau, il faut avoir une couilles quelque part... ou des millions de données.
 
Je sait que même si c'est pas l'idéal, j'ai déja bati des applis relativement grosses en réseau et avec pas mal d'enregistrements sous accèss.
 
Comme j'ai compris que ta base semblait être modeste, je pense qu'il y a un problème.
 
Peut tu détailler:
 
(1) Le nombre d'enregistrements dans la base.
(2) Le type de requête (Copie d'écran de la requête.)
(3) Le type de ton réseau ?
(4) Les OS des différents postes concernés.
(5) La version d'access.

Qd on commence à avoir des bases de 800 Mo à 1,6 Go il faut oublier access et passer par ex sous Microsoft SQL Server ou un autre SGDB.
 
De plus ce n'est pas tjs un pb hardware. En effet il est très facile d'ecrire (comme un porc) une requete qui mettra des jours à s'executer.
 
=> analyse La/Les requètes de tes utilisateurs.
=> analyse du nb d'enregistrements.
=> Dans ta base, tes tables sont-elles bien indexées (car une requete dont une condition s'effectue sur un champ non indexé sera tjs beaucoup plus longue que sur un champ indexé).
=> Reorganises-tu souvent ta base ?. (en la compactant par exemple).

 
Ca dépends de ce que tu fais.
 
Certes, access est connu pour être mauvais en réseau. Mais faut pas exagérer non plus.
 
Et puis, une abse de 50 Mo, c'est déja un gros truc.

 
Il faut voir les requetes mais 30 min avec une aussi grosse dase de donnée sous access c'est pas difficile d'y arriver.

 
Bien sûr, mais d'abord c'est quoi pour toi une grosse base ?
 
Avec 50.000 enregistrements, ça reste utilisable. Je l'ai fait pour une boite a l'époque des pentium 120 en réseau 10Mb.
 
J'ai pas compris qu'il avait une grosse base.

 
ben justement, 50mo c déjà énorme pour Access, alors là 800 mo au double  

Ah si, scusez. J'ai relu son truc.
 
Oauis, semblerait que ça puisse être gros.
 
On peut avoir le détail du nombre d'enregistrements totaux actuels ? Et rentrés par jour ?
 
Remarquez, mon appli était dans ce gout la aussi : Ca tournait.

 
Ah ouais, ok, j'ai relu le tomik.
 
Ouais, la c'est clair que c'est même pas la peine d'y penser.
 
Mais attends, 800 mo ?
 
C'est quand même bizarre.
 
Parce que pour faire 800Mo, faut une armée de gens qui saisissent.
 
Sérious, faudrait plus d'infos.
 
On peut rien pour lui, si il nous en donne pas.

Il faut voir le nombre de jointures, comment sont fait les indexs.
Pour faire ramer access il suffit une petite requete avec ANY ou IN

Pour tt ce qui est base de donnée, moi j'y comprend rien, je suis absolument pas competent.
 
Mais bon pour vous expliqué un peut on est operateur de services donc on revend des minutes telephonique.
 
Tt les jours nos divers fournisseurs (colt, worldcom.....) nous envoie le details des communications de tt nos clients (bcp)
 
Ca chiffre en centaine de milliers de ligne pour la facturation

A mon avis la requete c un truc hyper con du genre tel ligne est compare a un tableau pour savoir a qui est le numero, ensuite on associe un tarifs a cette ligne en plus etc........

Et bien les chefs de projets qui ont pondu cela sont encore pire que ceux de ma boite, je pensais pas que ça existait ...

sérieusement une bd access de 800mo c catastrophique
 
faut vraiment pensé à migrer sur autre chose, quitte a devoir investir un peu

une base access de plus de 10Mo c'est déconseillé, alors une base de plus de 1Go, ça fait presque peur  

 
Tu sais ya jamais eu de prjet.
 
On a commencé avec 4 cleints (avant on graver sur des cailloux) et voila aujourd'hui ou on en est.
 
La personne qui gere ca n'a aucune formation, il bidouile...mais ca marche super bien (lentement) mais bien.
 
C sure que un jours on va changer tt ca, mais pour nous en plus d'une histoire de cout, c plus facile de tt gerer en interne.

ouin bin avec un bd de 800mo jusqua 1.6go, c que le bidouilleur a bo essayé, il fait vraiment pas le boulot

le jours où toutes les données de votre base seront perdues, vous perdrez beaucoup plus que ce que vous aurait couté une petite appli avec un vrai SGBD derrière

 
TIVOLI STORAGE MANAGER powaaaaaaaaaaa
 
Bon je vais imprimer cette discution pour mon patron on va voir ce qu'il en dit...........LOL

Bon ben les test sont fait:
 
SI je fais sur mon PC = 2min
Sur le PIII en reseaux = 8min
Sur le PIII avec les données en local = 8min
 
 
Je crois que les chifrre parlent d'eux meme, c vraimment un probleme de CPU

 
tout ce temps juste pour ouvrir la base ?
y'a pas ke le cpu en + y'a aussi la ram & le diske dur ki doit gratter comme un fou

j'ai une question bete, mais tu fais des compactages de ta base tous les combien?
en plus meme 2 mns pour une requete c pas bon. ya trop de boucles ou je ne sais quoi mais quand tu comptes le temps perdu, t'amortiras tres vite un vrai sgbd.

 
Comme deja dit plus haut je n'y connait absolument rien en base de données et pour moi compactage ca veut pas dire grand chose.
 
Mais je vien de demander au gras qui s'en occupe et il le fait une fois par mois. (avant facturation)