Vous m'aviez répondu sur le code source vba France quant à une question que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd
qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver.
Cependant, nous voulons conserver également notre application sous access
pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule
application qui devra gérer Access et sqlserver tout en maintenant nos
performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il
va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si on
fait une requête du type : « select * from client where codepostal='56580
», doit-on mettre un index sur le champ codepostal pour accélérer les
performances?
- Comment faut-il utiliser les curseurs client et les curseurs
serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select .
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les
enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez m'apporter
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique Peralta
Utiliser les tables liées et rester en .mdb, si les performances actuelles sont correctes.
"Pierre-Yves" a écrit dans le message de news:
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver. Cependant, nous voulons conserver également notre application sous access pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule application qui devra gérer Access et sqlserver tout en maintenant nos performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580 », doit-on mettre un index sur le champ codepostal pour accélérer les performances?
- Comment faut-il utiliser les curseurs client et les curseurs serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
m'apporter
Cordialement
Utiliser les tables liées et rester en .mdb, si les performances actuelles
sont correctes.
"Pierre-Yves" <py_leteste@hotmail.com> a écrit dans le message de
news:uhimFVyGEHA.3816@TK2MSFTNGP10.phx.gbl...
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd
qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver.
Cependant, nous voulons conserver également notre application sous access
pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule
application qui devra gérer Access et sqlserver tout en maintenant nos
performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il
va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580
», doit-on mettre un index sur le champ codepostal pour accélérer les
performances?
- Comment faut-il utiliser les curseurs client et les curseurs
serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les
enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
Utiliser les tables liées et rester en .mdb, si les performances actuelles sont correctes.
"Pierre-Yves" a écrit dans le message de news:
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver. Cependant, nous voulons conserver également notre application sous access pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule application qui devra gérer Access et sqlserver tout en maintenant nos performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580 », doit-on mettre un index sur le champ codepostal pour accélérer les performances?
- Comment faut-il utiliser les curseurs client et les curseurs serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
m'apporter
Cordialement
Michel Walsh
Salut,
Également voir la réponse au message précédemment posté.
J'ajouterais que perso, je n'opterais pas pour MS SQL Server pour une question de vitesse. Risque d'être déçu. Par contre, si il y a des problèmes de stabilté en vue (liens WAN ou possibilités de perte fréquente de connexion), ou des problèmes de temps réel (disons plus de 45 énoncés INSERT VALUES à la seconde, ou tout autre problème de synchronisation serré), alors là, oui.
Si le programme est actuellement lent, revoir le programme. J'imagine qu'on a déjà quelque chose en deux-plis (front end pour l'appli, back end pour le data), sinon, c'est la première chose à faire. De plus, revoir si des tables ne pourraient pas être "en local", revoir si il est important d'avoir un liste de x-milliers d'items dans les combo box, avoir six sous-formulaires (via des onglets, et un seul est réellement visible), et autre trucs du genre. Quelque base de données, dans ces conditions, ne changera rien, si ce n'est adversement... à moins d'avoir des tables "carrées" (peu d'inter-relations) ... dans ce cas, Fox peut être plus performant. Mais si on utilise des Seek, j'ai l'impresion que de modifier l'approche, modifier l'énoncé SQL pour incorporer le WHERE dans l'énoncé, fera, de lui-même, une amélioration observable. Et si, dans un second temps, on décide de migrer vers MS SQL Server, ce sera celà moins de travail à refaire. :-)
Espérant être utile, Vanderghast, Access MVP.
"Pierre-Yves" wrote in message news:
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver. Cependant, nous voulons conserver également notre application sous access pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule application qui devra gérer Access et sqlserver tout en maintenant nos performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580 », doit-on mettre un index sur le champ codepostal pour accélérer les performances?
- Comment faut-il utiliser les curseurs client et les curseurs serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
m'apporter
Cordialement
Salut,
Également voir la réponse au message précédemment posté.
J'ajouterais que perso, je n'opterais pas pour MS SQL Server pour
une question de vitesse. Risque d'être déçu. Par contre, si il y a des
problèmes de stabilté en vue (liens WAN ou possibilités de perte fréquente
de connexion), ou des problèmes de temps réel (disons plus de 45 énoncés
INSERT VALUES à la seconde, ou tout autre problème de synchronisation
serré), alors là, oui.
Si le programme est actuellement lent, revoir le programme.
J'imagine qu'on a déjà quelque chose en deux-plis (front end pour l'appli,
back end pour le data), sinon, c'est la première chose à faire. De plus,
revoir si des tables ne pourraient pas être "en local", revoir si il est
important d'avoir un liste de x-milliers d'items dans les combo box, avoir
six sous-formulaires (via des onglets, et un seul est réellement visible),
et autre trucs du genre. Quelque base de données, dans ces conditions, ne
changera rien, si ce n'est adversement... à moins d'avoir des tables
"carrées" (peu d'inter-relations) ... dans ce cas, Fox peut être plus
performant. Mais si on utilise des Seek, j'ai l'impresion que de modifier
l'approche, modifier l'énoncé SQL pour incorporer le WHERE dans l'énoncé,
fera, de lui-même, une amélioration observable. Et si, dans un second temps,
on décide de migrer vers MS SQL Server, ce sera celà moins de travail à
refaire. :-)
Espérant être utile,
Vanderghast, Access MVP.
"Pierre-Yves" <py_leteste@hotmail.com> wrote in message
news:uhimFVyGEHA.3816@TK2MSFTNGP10.phx.gbl...
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd
qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver.
Cependant, nous voulons conserver également notre application sous access
pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule
application qui devra gérer Access et sqlserver tout en maintenant nos
performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il
va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580
», doit-on mettre un index sur le champ codepostal pour accélérer les
performances?
- Comment faut-il utiliser les curseurs client et les curseurs
serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les
enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
Également voir la réponse au message précédemment posté.
J'ajouterais que perso, je n'opterais pas pour MS SQL Server pour une question de vitesse. Risque d'être déçu. Par contre, si il y a des problèmes de stabilté en vue (liens WAN ou possibilités de perte fréquente de connexion), ou des problèmes de temps réel (disons plus de 45 énoncés INSERT VALUES à la seconde, ou tout autre problème de synchronisation serré), alors là, oui.
Si le programme est actuellement lent, revoir le programme. J'imagine qu'on a déjà quelque chose en deux-plis (front end pour l'appli, back end pour le data), sinon, c'est la première chose à faire. De plus, revoir si des tables ne pourraient pas être "en local", revoir si il est important d'avoir un liste de x-milliers d'items dans les combo box, avoir six sous-formulaires (via des onglets, et un seul est réellement visible), et autre trucs du genre. Quelque base de données, dans ces conditions, ne changera rien, si ce n'est adversement... à moins d'avoir des tables "carrées" (peu d'inter-relations) ... dans ce cas, Fox peut être plus performant. Mais si on utilise des Seek, j'ai l'impresion que de modifier l'approche, modifier l'énoncé SQL pour incorporer le WHERE dans l'énoncé, fera, de lui-même, une amélioration observable. Et si, dans un second temps, on décide de migrer vers MS SQL Server, ce sera celà moins de travail à refaire. :-)
Espérant être utile, Vanderghast, Access MVP.
"Pierre-Yves" wrote in message news:
Bonjour,
Vous m'aviez répondu sur le code source vba France quant à une question
que
je me posais concernant notre migration sqlserver le 2/04/04
Je me permets donc de vous recontacter pour m'éclaircir sur certains
points.
Notre situation :
Nous avons actuellement notre application sous access. Access est une bdd qui convenait tout à fait à nos clients. Désormais, nous nous attaquons à
de
plus gros clients, ce qui nécessite le passage d'access vers sqlserver.
Nous souhaitons donc migrer notre application d'access vers sqlserver. Cependant, nous voulons conserver également notre application sous access pour nos plus petits clients. En fait, on ne veut maintenir qu'une seule application qui devra gérer Access et sqlserver tout en maintenant nos performances sur access
Plusieurs se posent donc :
- il faut que l'on conserve nos performances sur access
- les méthodes seek n'étant plus dispo pour attaquer sqlserver, il va donc falloir les transformer en select . where
- Comment se passe la gestion des index sous sqlserver ? ex : si
on
fait une requête du type : « select * from client where codepostal='56580 », doit-on mettre un index sur le champ codepostal pour accélérer les performances?
- Comment faut-il utiliser les curseurs client et les curseurs serveur sur sqlserveur ?
- Va-ton perdre des performances en remplaçant le seek par select
.
where dans access ?
- Comment se passe la gestion des accès concurrentiels sur les enregistrements dans sql server ?
Je vous remercie d'avance pour tous les conseils que vous pourrez
