Salut,
Si je comprends bien...
La base à laquelle tu lie la table n'est pas locale, mais se trouve sur
le "serveur" et tout le monde à un raccourci vers cette base ?
Si c'est cela, la méthode est (très) mauvaise et encore heureux que cela
ne fonctionne pas comme tu le souhaite.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Salut,
Si je comprends bien...
La base à laquelle tu lie la table n'est pas locale, mais se trouve sur
le "serveur" et tout le monde à un raccourci vers cette base ?
Si c'est cela, la méthode est (très) mauvaise et encore heureux que cela
ne fonctionne pas comme tu le souhaite.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Salut,
Si je comprends bien...
La base à laquelle tu lie la table n'est pas locale, mais se trouve sur
le "serveur" et tout le monde à un raccourci vers cette base ?
Si c'est cela, la méthode est (très) mauvaise et encore heureux que cela
ne fonctionne pas comme tu le souhaite.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
et donc chacun démarre cette MDE du serveur A ?
toutes les tables sont donc liées à la MDE du serveur A ??
ce qui a (aurait) comme résultat que la base utilise le moteur JET
(serveur de fichier)
annulle(rait) presque totalement l'avantage de l'utilisation de SQL Server
!
- je ne connait pas d'application ou "untel" à le besoin de créer une
table
(accessible par tous), si ce n'est justement en local pour un usage qui
lui
est propre (rapatriement de données pour des stats ou autres "travaux
lourds")
J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
mieux",
mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
et/ou
moins performant qu'une application totalement basée sur de l'Access, mais
bien pensée.
et donc chacun démarre cette MDE du serveur A ?
toutes les tables sont donc liées à la MDE du serveur A ??
ce qui a (aurait) comme résultat que la base utilise le moteur JET
(serveur de fichier)
annulle(rait) presque totalement l'avantage de l'utilisation de SQL Server
!
- je ne connait pas d'application ou "untel" à le besoin de créer une
table
(accessible par tous), si ce n'est justement en local pour un usage qui
lui
est propre (rapatriement de données pour des stats ou autres "travaux
lourds")
J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
mieux",
mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
et/ou
moins performant qu'une application totalement basée sur de l'Access, mais
bien pensée.
et donc chacun démarre cette MDE du serveur A ?
toutes les tables sont donc liées à la MDE du serveur A ??
ce qui a (aurait) comme résultat que la base utilise le moteur JET
(serveur de fichier)
annulle(rait) presque totalement l'avantage de l'utilisation de SQL Server
!
- je ne connait pas d'application ou "untel" à le besoin de créer une
table
(accessible par tous), si ce n'est justement en local pour un usage qui
lui
est propre (rapatriement de données pour des stats ou autres "travaux
lourds")
J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
mieux",
mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
et/ou
moins performant qu'une application totalement basée sur de l'Access, mais
bien pensée.
re,
"Denis"
| Je pense effectivement que cette application peut être classée dans
"travaux
| lourds" : elle permet de stocker/gérer les logs d'une trentaine de
serveur
| (pour l'instant):
| Pour chaque controleur de domaine, une table lui est dédiée / créée lors
de
| son ajout.
| La quantité des logs stockés est énorme ne serait-ce que pour un serveur
| .... je ne peux pas me permettre de tout mettre dans une seule et unique
| table ...
|
|
| > J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
| > mieux",
| > mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
| > et/ou
| > moins performant qu'une application totalement basée sur de l'Access,
mais
| > bien pensée.
|
| Le serveur SQL était déjà en place avec plusieurs bases à sa charge :
j'ai
| pensé, (à juste titre aux vue des bénéfices en terme de rapidité
d'exécution
| de requête) qu'il serait judicieux d'en profiter.
Si les tables sont réellement liées, que tu n'utilise pas les procédures
stockées...
il faudra me convaincre par quel miracle tu as obtenu ce gain en rapidité
!!
Tu utilise Access de façon conventionnelle (hormis le fait que tu as
l'appli sur
le serveur, ce qui entre autre, obligent les formulaires et le reste à
transiter
aussi par le réseau) et dans ce cas, c'est JET, serveur de fichiers
faut-il le
rappeller, qui fait le boulot. Dans cette configuration, les données
transitent via
le réseau de la même manière qu'une simple base Access...
Mais bon, l'important est ta satisfaction et non la mienne ;-)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
re,
"Denis"
| Je pense effectivement que cette application peut être classée dans
"travaux
| lourds" : elle permet de stocker/gérer les logs d'une trentaine de
serveur
| (pour l'instant):
| Pour chaque controleur de domaine, une table lui est dédiée / créée lors
de
| son ajout.
| La quantité des logs stockés est énorme ne serait-ce que pour un serveur
| .... je ne peux pas me permettre de tout mettre dans une seule et unique
| table ...
|
|
| > J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
| > mieux",
| > mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
| > et/ou
| > moins performant qu'une application totalement basée sur de l'Access,
mais
| > bien pensée.
|
| Le serveur SQL était déjà en place avec plusieurs bases à sa charge :
j'ai
| pensé, (à juste titre aux vue des bénéfices en terme de rapidité
d'exécution
| de requête) qu'il serait judicieux d'en profiter.
Si les tables sont réellement liées, que tu n'utilise pas les procédures
stockées...
il faudra me convaincre par quel miracle tu as obtenu ce gain en rapidité
!!
Tu utilise Access de façon conventionnelle (hormis le fait que tu as
l'appli sur
le serveur, ce qui entre autre, obligent les formulaires et le reste à
transiter
aussi par le réseau) et dans ce cas, c'est JET, serveur de fichiers
faut-il le
rappeller, qui fait le boulot. Dans cette configuration, les données
transitent via
le réseau de la même manière qu'une simple base Access...
Mais bon, l'important est ta satisfaction et non la mienne ;-)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
re,
"Denis"
| Je pense effectivement que cette application peut être classée dans
"travaux
| lourds" : elle permet de stocker/gérer les logs d'une trentaine de
serveur
| (pour l'instant):
| Pour chaque controleur de domaine, une table lui est dédiée / créée lors
de
| son ajout.
| La quantité des logs stockés est énorme ne serait-ce que pour un serveur
| .... je ne peux pas me permettre de tout mettre dans une seule et unique
| table ...
|
|
| > J'ai donc l'impression que l'on a installé SQL Server "parce que c'est
| > mieux",
| > mais qu'il résulte de la mise en oeuvre quelque chose de moins propre
| > et/ou
| > moins performant qu'une application totalement basée sur de l'Access,
mais
| > bien pensée.
|
| Le serveur SQL était déjà en place avec plusieurs bases à sa charge :
j'ai
| pensé, (à juste titre aux vue des bénéfices en terme de rapidité
d'exécution
| de requête) qu'il serait judicieux d'en profiter.
Si les tables sont réellement liées, que tu n'utilise pas les procédures
stockées...
il faudra me convaincre par quel miracle tu as obtenu ce gain en rapidité
!!
Tu utilise Access de façon conventionnelle (hormis le fait que tu as
l'appli sur
le serveur, ce qui entre autre, obligent les formulaires et le reste à
transiter
aussi par le réseau) et dans ce cas, c'est JET, serveur de fichiers
faut-il le
rappeller, qui fait le boulot. Dans cette configuration, les données
transitent via
le réseau de la même manière qu'une simple base Access...
Mais bon, l'important est ta satisfaction et non la mienne ;-)
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
