Bon la je cmmence à désespérer un chouilla
 
Bref faut que j'exporte le résultat d'une requête dans n'importe koi, de préférence un fichier texte ou Excel.
Alors avec Sql Server 2000 j'ai bien la soluce du DTS mais il me sort une erreur qd j'utilise l'assistant et que je lui place ma requete.  
Et sinon dans la doc j'ai pas trouve cmt creer ces lot sans utiliser l'assistant, parce que je vx pouvoir les creer sur une appli Php
 
Vous auriez pas une idée .............. ???

Tu peux toujours créer le fichier depuis PHP non ?
 
Sinon, en effet, je ne sais pas comment créer un lot DTS sans passer par l'assistant, bien que ça doive être possible.
 
Sinon, pour "faciliter" le travail, si tu met en suffix à ta requête "for xml auto", alors tu récupèreras le résultat dans un fichier XML structuré, ce qui te donne un format standard d'export.

Ah ,précision, faut que la procédure s'execute en étant planifier, donc php doit pas intervenir dans l'exécution mais pourquoi pas dans la planification !

Sinon, depuis une procédure T-SQL, tu peux créer un fichier sur le disque, et même un Objet Excel, et jouer avec.
Ca reste une solution possible...

Euh, c normal que la doc soit pas claire la dessus, et que j'y comprenne rien a ce qu'est marque ?
Pourtant SQL connais, mais Transact-SQL ....

Tiens, essaie-ça, c'est pas très propre, mais ça marche
 

Elle existe pr toi la table tsttbl, faut que je la cree po tester ta procedure?
En fait g déjà fait du transact SQL mais je pensais pas que c'était ca, j'ai fait des procédurecomme ca par ex :
 

Euh... Ouais, mais bon, là, ta procédure, elle fait pas un fichier hein
 
Sinon, oui, la table tsttbl, c'est une table que j'ai créé pour faire mon test (comme son nom l'indique).
 
Mixe juste ton code avec le mien, et normalement, t'as ça en sortie (dans le fichier c:\sql_out.txt)
 

Ok, j'te remercie, ca a l'air de donner quelque chose, apres je sais pas si je vais pouvoir executer ce code en différé.
mais le ficheir a déjà une bonne tronche de ce que j'attendais !

J'ai encore un prob avec la soluce que tu m'as filé
J'ai réussi à générer mon fichier, et je peux exécuter la procédure avec mon utilisateur principal(celui qui a créé la base).
Mais je ne souhaite pas l'employer pour faire ces traitements, j'ai créé des utilisateurs avec moins de drotis (c'est plus prudent).
Problème c'est qu'il faut des autorisations pour l'exécution de la commande xp_cmdshell sinon il me sort ceci :
 
Msg. 50001, Niveau 1, État 50001
xpsql.cpp : Erreur 87 de GetProxyAccount sur la ligne 604
 
Quels droits je dois autoriser pour pouvoir l'effectuer correctement

OK, je reproduis ton problème :
 

 
Résolu avec la démarche suivante :
- Dans la base "master", crée un user utilisant la connection de l'utilisateur de ta base
- Dans "Procédure stockées étendues", ajoute le droit "EXEC" à cet utilisateur sur la procédure "xp_cmdshell"
 
Par contre, après, chez moi ça plante plus loin
 

 
A creuser

Argh, merde, j'avais pas lu jusqu'au bout, t'en es déjà là

Pfff, je trouve même pas comment on peut se connecter en tant qu'un autre utilisateur depuis une commande SQL. Ce serait à mon avis le plus simple :
dans la procédure, tu te connectes en tant que dbo
tu fais les cmdshell
tu déconnecte dbo
 
Mais je trouve pas où c'est
 
Ce qui est très con, c'est que si tu fait une vue sur une table.
Tu interdis la lecture de la table à un utilisateur
Tu l'authorise à lire la vue
=> Il peut voir les données de la table interdite via la vue.  
 
Mais ça n'a pas l'air de marcher pareil avec les procédures stockées

Bon, j'ai pas pu contourner le prob
alors ce que je fais, c'est que j'exécute ces procédures lors de planifications
Comme ca c'est le créateur de ma base (qui réussit à exécuter ces procédures avec son droits sysadmin sur le serveur) qui les planifie. Après faut juste récupérer les fichiers généré et c'est bon
De toute façon c'est une procédure qu'il vaut mieux planifier pour faire les stat par mois (sans en oublier)
 
Merci qd même de ton aide
 
PS : si tu vx que ca fonctionne avec un autre utilisateur, j'ai trouvé que le moyen de lui mettre sysadmin (pas très pro tt ça)

Sinon, j'ai des problmes sur la longueur du champ qui contient la commande dans xp_cmdshell
Dans la doc, c'est marque qe c'est un VARCHAR(255) ou un NVARCHAR(4000)
 
Quand j'entre ceci en parametre :  

 
eh bien je me retrouve avec un fhcier de ce nom : StatProspects_08
Alors qu'il devrait contenir : StatProspects_08.06.05
 
est-ce que c'est possible d'augmenter la taille de ce paramètre ?
 
Autre question, les accents sont très mal exportés, ils sont stockés tel quel dans la base mais dans les fichiers c du n'importe quoi : y'a une soluce ?

essaie de mettre de " autour du nom de fichier dans la commande ?
 
en effet, CMD est une émulation de DOS, et comme chacun sait, on peut pas avoir 36 . dans un nom de fichier DOS. Je pense qu'il faut donc que tu l'échappes afin de lui faire comprendre qu'on n'est plus en 1985 mais en 2005

sinon, pour les accents, nan, pas de solution : le fichier est stocké en ASCII.
 
logiquement, quand tu fais ouvrir dans notepad, si tu choisi le même encodage que celui de ta base, tu devrais retomber sur tes pattes.

Non, toujours le même problème
J'ai essayé les simples quotes ', et les doubles "
Rien y fait !

Sinon pour l'encodage en ASCII, si je l'ouvre avec Notepad++, il me l'affiche en ANSI.
Et j'ai pas trouvé comment convertir en ASCII dans notepad, ou dans wordpad !