Version imprimable
Bonjour à tous,
Je suis en pleine création d'une application Access qui se base sur des tables SQL Server.
Pour effectuer des modifications sur les tables, vaut-il mieux utiliser le SQL dans Access ou prévoir des procédures stockées sur SQL Server et appeler ces procédures avec des paramètres ?
La question relève plus de la performance mais également en terme de sécurité et de facilité d'utilisation (mise à jour , etc...) !
J'ai déjà posté sur le forum Access mais sans succès !
Merki
Bonjour,
la procédure stockée, c'est la grande invention du siècle (dernier) ! Bien sûr c'est mieux, bien sûr la sécurité et les performances sont meilleures, bien sûr c'est plus facile à maintenir...
Mais je me demande : si tu fais une appli Access, tu vas utiliser des formulaires liés aux données ? Et tu vas faire l'insert par événement BeforeInsert ou qqch comme ça (ça fait qq années que je n'ai plus ouvert Access) ?
En faveur des procédures :
- tu peux donner des droits sur les procédures seulement et l'enlever des tables, donc tu maîtrises totalement l'accès aux tables
- si tu dois mettre à jour une requête, tu lances un script sur le serveur SQL au lieu de reshipper ton fichier Access.
et bien d'autres.
Salut,
Merci pour ta réponse sur les procédures.
Concernant Access, je vais effectivement utiliser des formulaires avec tables liées vers SQL Server. A ce jour, je n'ai pas beaucoup avancé dans la conception mais je me renseigne avant d'aller plus loin.
J'imagine utiliser les procédures stockées pour mettre à jour toutes les informations. Eventuellement, je pensais utiliser les formulaires juste pour faire apparaître les informations. Dans le cas d'un souhait de modification de l'information affichée, je ferais apparaître un autre formulaire plus aisé pour la modification et après validation, j'utiliserai une procédure stockée pour la mise à jour.
Je ne connais pas bien les SQL server et je me demande : lorsqu'on utilise une procédure, elles peuvent retourner une ou plusieurs valeurs en guise de résultat ?
Ne serais-tu pas au bord d'utiliser un autre client qu'Access ? Par exemple Delphi ou .NET en WinForms ? Parce que là tu commences à décrire du bon vieux client/serveur.
Certes, les états imprimés peuvent poser problème, mais le générateur d'états de Delphi fait de bonnes choses (à mon avis).
Tu peux faire du bon boulot en .NET pour pas un rond avec SharpDevelop ou Visual Studio Express...
Bon, ta question c'était SQL ;) ...
La procédure peut retourner :
- un ou plusieurs recordsets
- un ou plusieurs paramètres retour (OUTPUT), qui se comportent fonctionnellement comme des paramètres par référence
- une valeur de retour (entier)
Une procédure stockée est préférable que toute version de SQL Direct.
En effet :
1-Pas besoin de recompiler ton application en cas de modification du corps de la procédure
2-Optimisation du trafique réseau du au fait que seul le nom de la procédure (et les paramètres) est envoyé au serveur.
3-Optimisation des performances : Le serveur n'a plus besoin de refaire le plan d'execution de la procédure
4-Sécurité, impossible de s'injecter dans votre application par SQL Injection
5- Code Client plus lisible.
Il vaut mieux l'adopter.
Si c'est pour des raisons de rapports, Visual Studio 2005 intègre l'editeur d'état cristal Report.
Bonne chance.
Moi personnelement je suis entrain de developper un projet adp "access" avec une base de donnée sqlserver. je trouve que c'est plus faciles et j'utilise pas mal de procédure stokée.
le projet adp se comporte comme si c'est une base de donnée access. il agit directement sur les tables ou les vues.