Bonjour!
 
Bon, j'ai un petit soucis avec mon sql serveur 2000, je n'arrive pas a trouver le moyen de faire ce que je veux.
Je precise de suite, mon modele de donnees est lamentable, mais ca, je dois faire avec
 
En gros, je veux faire une fonction (jusque la, ca va) qui elle meme doit utiliser un exec (la ca ne va plus).
Pourquoi utiliser un exec?
Parceque j'ai un nom de table en parametre de ma fonction et je n'ai pas trouve d'autres moyen qu'un exec pour executer une sous-requete avec.
 
En gros j'ai une variable @table et j'ai besoin dans ma fonction de faire un truc comme:
 
exec('select * from ' + @table)
 
Or, impossible d'utiliser d'exec dans les fonctions!
 
J'ai essaye avec execute sp_executesql, il accepte la syntaxe de ma fonction mais plante a l'execution avec comme message:
"Seules les fonctions et les procédures étendues peuvent être exécutées à partir d'une fonction."
 
Je pourrais evidement utiliser une procedure stocke et un curseur a la place de ma fonction, mais ca m'obligerais a reecrire beaucoup de requetes...
 
Y a t-il un moyen de feinter?
 
merci!

Tu te connectes comment à ton système de base ?  
Il devrait y a voir des composants, des classes qui te permettent de gérer la connection et les requêtes au système.

Je ne sais pas si c'est ce que tu demande (ni si j'ai ete clair au debut) mais quand je parle de fonction et d'exec, c'est tout sur le serveur sql.
Donc j'y accede soit avec l'anaylseur de requete soit l'Entreprise Manager.
 
Et donc en declarant une fonction en t-sql (CREATE FUNCTION) je n'arrive pas a trouver un moyen d'utiliser une variable comme nom de base.
D'habitude lorsque je passe par une procedure stocke, j'utilise la commande EXECUTE suivie de ma requete sous forme de string (nvarchar par ex) mais comme on ne peut pas utiliser cette commande dans une fonction, je bloque...

Ah ok. Je ne savais pas qu'on pouvait avoir des variables comme ton @table  
Dans ce cas, impossible de te filer un coup de main

En fait tu peux avoir des variable table temporaire (jamais essaye, mais pas vraiment optimal) et la j'utilise dans ma variable @table une bete chaine de caractere avec le nom de la table, je concatene tout ca pour construire une requete 'dynamique' que j'execute avec la commande exec.
 
Le probleme c'est qu'autant ca marche dans les procedures stockes que pas du tout dans les fonctions...
 
D'ailleur il ne veut meme pas executer une procedure stocke depuis une fonction (en utilisant exec sp_executesql) mais a priori il veut bien le faire pour des procedure etendues...
Or d'apres la doc, les procedures etendues sont comme les normales sauf que ce sont des modules compiles qui s'execute dans le meme espace memoire...
 
J'aime pas ce genre de limitations
 
Si sql server 2005 corrige ca, hop, je fonce

Ta fonction retourne quoi ? Si c'est une table, t'es baisé.
Si c'est une variable, alors passe par une procédure et renvoie le résultat avec un paramètre output.
 
Si c'est une table, t'as toujours le moyen de passer par une table temporaire...

Ouaip, merci, au final je suis passe par une procedure mais ca m'a oblige a modifier mes requetes pour utiliser un curseur pour etre capable de reccuperer ligne par ligne le contenu de mes variables.
 
C'est pas l'ideal vu que les performances chutes avec le nombre d'enregistrement, mais c'est le plus simple dans mon cas!
 
Ca reste tres frustrant d'etre bloque sur des trucs comme ca quand meme
 

En fait, la limitation viens d'une aute limitation du moteur.
 
Pendant une requête, MS SQL Server 2000 est incapable de bloquer l'heure interne... Et encore moins si cette heure provient d'outils annexes.
 
Pour cette raison, les FONCTION doivent impérativement être "je sais plus le terme", c'est à dire produire un résultat que le temps ne peut influencer.
 
Par exemple, il est impossible d'appeler GUID() ou RAND() dans une fonction, car chaque appel, avec les mêmes paramètres, dans le même environnement et la même transaction retournera des valeurs différentes.
 
Dans une requête du type :
 

Représente bien le problème.
 
Si durant le seclect, le comportement de "myFunction()" évolue, on va avoir un comportement étrange et une requête qui dont le résultat n'a pas de sens. Par exemple, si la fonction fait un test sur la date, et si entre 9am et 6pm elle retourne 1 et 0 sinon, alors si on lance la requête à 5:59pm et qu'elle dure deux secondes, on est comme des cons. Le moteur ne sâchant limiter que "Date()" on n'a pas de souci dans ce cas... Mais pour tous les autres (notamment un EXECUTE, qui tourne dans un espace séparé, donc une valeur de "Date()" différente), ça marche pas.
 
Une procédure n'a pas cette limitation (car normalement, on ne l'appelle pas au sein d'une requête, donc si le résultat évolue d'une ligne à l'autre, ce n'est pas grave).
 
Donc... Afin d'empêcher les fonctions d'avoir un comportement dépendant du temps, ils ont bloqué l'appel aux procédures depuis les fonctions.
 
C'est un peu con en effet mais bon, c'est la vie

"déterminisitiques" le terme, ou un truc du genre

 
C'est "déterministe".

ouais s'pareil

En tout cas, c'est con
 
On sait si SQL 2005 est moins... 'con' ?

Ben... Ca demande certainement la réécriture d'une grande partie du moteur SQL.
La version 2005 semble plutôt être une simple évolution du moteur de 2000, donc il y a de grandes chances pour que non. Ceci dit, je n'ai jamais testé la nouvelle version, pas plus que je ne me suis intéressé aux réelles évolutions du moteur, donc c'est à vérifier.