Ouais, alors la on rentre un peu dans la tetrapilectomie(*), hein.
En effet il faudrait comparer la taille de la requête avec la taille de la requête d'exécution de la proc stoc. :D
(*) l'art de couper les cheveux en quatre.
Version imprimable
Bonjour,
Désolé de réanimer cette belle conversation, mais j'aurai une question qui a raport avec ce que vous discuter depuit tout a l'heure.
Vous parler de mettre les requete dans des procedure stocké pour les requete de type insert,update et delete. Pour sa aucun problème.
Mais que faite vous avec les requête Select ?
Vous les placer elle aussi dans des procédure stocké ou vous faite autrement ?
merci
Je ne sais pas si je comprend bien. Quand vous parler de mettreles requete dans des procédure stocké vous parler bien de les exécuté directement dans la procédure ? ou bien vous vouler dire que la procédure stocké renvois la requete.
Car si c'est le premier choix alors je ne comprend pas comment vous faite pour que sa marche avec un Select qui retourne plusieurs donné. Qu'est-ce que la procédure renvois dans ce cas.
merci
Bien sur ! le cas contraire aurait peu d'interêt.
Euh ... en général on est plus intéressé par le résultat que par la requête, non ?Citation:
ou bien vous vouler dire que la procédure stocké renvois la requete.
Les données. C'est d'ailleurs ce qu'on lui demande.Citation:
Car si c'est le premier choix alors je ne comprend pas comment vous faite pour que sa marche avec un Select qui retourne plusieurs donné. Qu'est-ce que la procédure renvois dans ce cas.
Elle peut aussi avoir une valeur de retour (en plus), ainsi que des paramètres "output".
Désoler je vien de regarder de plus près les procédure stocké et je vien de me rendre compte qu'on peut lire les donné avec un reader comme si on l'aurai exécuté directement.
Sinon cette manière de faire est utile pour pas avoir a recompiler mais si les paramètre qu'on passe a la procedure change je parie qu'on va devoir recompliler le programme aussi.
Le seul problème que je vois a cette mannière de faire est le fait qu'il faut trouver des nom a nos procédure stocké :aie: et aussi que a la fin d'un gros programme il doit y avoir beaucoup de procédure stocké pour les requette dans la base ( je sais que c'est pas grave pour la taille, mais pour l'encombrement sa peut devenir perdu)
sinon dernière petite question. Qu'elle-est la difference entre une fonction et une procedure stocké en sql ?
merci
C'est un fait, mais ce n'est pas le cas le plus courant.
Comme pour les classes, les méthodes, les NS, etc .. : il faut adopter un schéma de nommage (de préférence au niveau corp. , ou, le cas échéant, au niveau projet) et s'y tenir.Citation:
( je sais que c'est pas grave pour la taille, mais pour l'encombrement sa peut devenir perdu)
Les differences sont très nombreuses et on sort du cas d'une explication en quelques lignes.Citation:
sinon dernière petite question. Qu'elle-est la difference entre une fonction et une procedure stocké en sql ?
Mais pour faire cours, une proc stoc peut faire "presque" tout ce que fait une fonction mais pas l'inverse. Les fonctions sont de plus limitées dans leur accès aux données. (de plus il y a trois types de fonctions, les "Table-valued Functions" ressemblant un peu et de loin aux proc stoc retournant une liste de données).
En revanche on peut mettre une fonction directement dans une requête
Exemple : (avec une fonction d'agrégat : pas d'équivalent en proc stoc)
Ce qui est impossible avec une proc stoc.Code:select MyAggregateFunc(MyField1) from MyTable1
A noter qu'avec Sql Server 2005 et + , les fonctions comme les proc stoc peuvent être aussi bien développées en C# qu'en T-SQL. (ce qui est ,parfois mais c'est rare, très pratique mais amène aussi certaines contraintes).
oui c'est bien pratique oui, il suffit que la SP se termine par un select, et on peut par exemple faire des insert dans une table # puis faire le select
oui
trouver un nom à la procédure stocker c'est un avantage, au moins on sait ce que tu as voulu faire dans la procédure si tu la nommes CreateLivreur
après oui c'est dommage qu'sql server ne permette pas de créer des dossiers pour les ranger un peu, car dépassé la centaines ca fait de l'ascenseur à manipuler et il faut aiguiser les yeux
comme en c# !
une procédure stockée c'est comme un void, ca exécute du code
et une fonction c'est comme une fonction, ca retourne quelque chose (une valeur pour les fonctions scalaires, une table pour les fonctions table)
edit j'ai été long à taper on dirait ^^
Pas tout à fait : une proc stoc peut avoir un retour et des paramètres output.
Ce qu'on ne peut pas faire du tout en proc stoc c'est l'équivalent d'une fonction aggrégat.
Mais entre une fonction scalaire et une proc stoc ce qu'apporte la fonction c'est la possibilité d'être appelée dans une requête.
Bien sur mais pas de retour puisque il est "void", alors qu'une proc stoc peut avoir : données en retour + code retour + paramètres ouput tout cela à lafois.
J'admet que la phrase était ambigüe mais il est difficile de comparer des fonction/proc stoc SQL Server avec des méthodes pas void/void C# : les possibilités des fonctions en T-SQL sont clairement limitées dans ce qu'il est possible de faire à l'intérieur du code - et c'est valable aussi pour les fonctions Sql Server SQLCLR en C# (ou en VB.Net d'ailleurs) qui sont soumises aux même limitations.
Pol63 a ta dernière remarque sur les plans d'exécution je n'ai rien à redire, et effectivement il faut bien toute une carrière pour le connaitre parfaitement ou alors se farcir tout le cursus de certifications associées à SQL Server :)
Comme il a été dit, autre intérêt de la procédure stockée, c'est qu'en plus d'un "resultset" elle peut retourner un code numérique, et elle peut retourner des valeurs par les paramètres output... ce qui est parfait pour cascader et remonter les erreurs.
La différence entre utiliser une procédure stockée et une requête au moment de le faire avec l'appli, se fait au niveau du plan d'exécution certes, mais au niveau de la notion de "batch"... une procédure stockée, comme une vue est TOUJOURS préparée, ce n'est pas le cas d'une requête par défaut, où il faudra l'envisager si on compte l'exécuter plusieurs fois d'affilée.
Sous Oracle il est nécessaire de forcer la "préparation", mais je ne sais plus s'il en est de même sur SQL Server 2008 R2... a vraie dire à force d'améliorer les produits, on fini par perdre le fil :)
MAis commes tous ce passe dirrectement sur sql server est-ce qu'on peut faire begintransaction en c# ou il faut faire les transaction (et les annuler si c'Est le cas) dirrectement sous sql server.
Sinon quelle son les autres moyen pour gardé des requête sql autre que dans des procédure stocké ? ( dans le cas ou je ne voudrai pas remplir toute mon dossier de procédure avec des centaines de procédure stocké pour mon programme)
c'est quoi l'intérêt?Citation:
MAis commes tous ce passe dirrectement sur sql server est-ce qu'on peut faire begintransaction en c# ou il faut faire les transaction (et les annuler si c'Est le cas) dirrectement sous sql server.
en quoi ça te gêne? ce dossier est fait pour stocker les proc stoc non?Citation:
Sinon quelle son les autres moyen pour gardé des requête sql autre que dans des procédure stocké ? ( dans le cas ou je ne voudrai pas remplir toute mon dossier de procédure avec des centaines de procédure stocké pour mon programme)
Donc je peux faire ca directement sous c# :
et avec ce code la (il se peux qu'il y ai des erreur dans mon code je l'ai fait vite) toute les insert, update ou delete vont être annuler ?Code:
1
2
3
4
5
6
7
8
9
10
11
12
13 transaction = connection.BeginTransaction(); Command.Transaction = transaction; try { Command.ExecuteNonQuery(); // Execution de la procedure stocké } catch { transaction.RollBack(); }
merci
Tout code SQL exécuté dans la connexion est concerné par la transaction, mémé les procédures stockées.
Merci beaucoup pour ta réponce sa répond a peut près a tous les intérogation que j'avais au niveau des procédure stocké
Je sais qu'il est fait pour sa mais quand il est bien remplis sa devien brouillon. Si on pourai faire des dossier pour les classé sa serai génial mais on peut pas.Citation:
en quoi ça te gêne? ce dossier est fait pour stocker les proc stoc non?
C'est pour sa que je demandais s'il y avait d'autre moyen pour envisager toute les solucion lors de mon prochain programme.
un proc stoc explorer ^^Citation:
Si on pourai faire des dossier pour les classé sa serai génial mais on peut pas.
tu peux organiser tes proc stoc en utilisant des préfixes
évite le préfixe "sp_" (pour éviter un conflit s'il y aura une proc stoc system qui portera le même nom que la tienne)
et il est recommandé aussi de ne pas utilisé ce préfixe car SQL Server recherche toujours une procédure stockée commençant par sp_ dans l’ordre suivant :
- elle existe dans la base de données master ;
- ensuite, en fonction des éventuels identificateurs fournis (nom de base de données ou propriétaire) ;
- enfin, avec dbo comme propriétaire si aucun propriétaire n’est spécifié.