[SQLCMD] Encodage et fichiers de sortie

Bonjour,

J'ai un problème avec l'utilisation de SQLCMD, appelé sur une seule ligne depuis la console.

Pour que mes données résultats soient correctement encodées, je n'ai trouvé comme solution que d'utiliser l'option -f1252 (codepage correspondant à ma base de données et je n'ai pas la main dessus).

Seulement voilà, cette option -f n'est utilisée que si l'option -o est utilisée pour indiquer le fichier de sortie (ou du moins j'en ai l'impression). Or dans ce cas, la sortie standard et la sortie d'erreur sont regroupées dans le fichier indiqué par -o.

Mon problème est qu'il me faut pouvoir distinguer, après l'exécution, ma sortie standard de ma sortie d'erreur. Effectivement dans certains cas - par exemple le cas où l'appel tombe en timeout -, SQLCMD ne positionne pas l'ERRORLEVEL et je ne détecte pas qu'il y a eu un problème. Pourtant les données ne sont pas valides du tout : la sortie contient juste le message indiquant le timeout atteint.

Arrivée là, j'ai le constat suivant :
- Soit j'utilise -f et -o et mes données sont correctement encodées, mais je ne détecte pas les timeout (problème bloquant dans mon cas)
- Soit j'utilise >1 et >2 pour rediriger les sorties, je peux détecter les erreurs en analysant la sortie d'erreur, mais mes données sont mal encodées... (bloquant aussi)

Est-ce que quelqu'un aurait une idée ? Ça fait plusieurs fois que je cherche et je ne trouve pas de solution :cry:
Merci d'avance !

SQLcmd n'est pas fait pour faire de l'export de données. Pour cela vous devez utiliser bcp.exe qui est l'utilitaire d'import export en ligne de commande et vous permet de piloter le mode d'encodage (wildchar, codepage, raw..).

A +

Merci pour la réponse.

Dans mon contexte particulier il m'est difficile d'utiliser BCP pour l'opération que je veux effectuer... Mais dans le cas où je pourrais, est-ce que BCP peut prendre en paramètre un chemin de fichier dans lequel il trouvera le script SQL permettant de récolter les données à exporter ? (rien vu de tel dans les options, mais comme je n'ai pas tout essayé, j'ai peut être loupé quelque chose)

Ma situation est la suivante : Je me connecte (via SQLCMD pour l'instant) sur une instance SQL, en utilisant un fichier contant un script SQL pour calculer les données à retourner. Il ne m'est pas possible de stocker des données sur cette instance (pour les récupérer par exemple avec un export BCP par la suite). Le calcul et l'export doivent donc se faire en une seule opération.

Merci encore pour la réactivité ;)

je ne voit rien qui empêche d'utiliser bcp qui, encore une fois, est fait pour cela !

A +

Bonjour

Désolé pour ma curiosité mais qu'est-ce qui t'empêche de lancer, par ex, un sqlcmd pour créer une vue correspondant à ta requête et de lancer le bcp à la suite (option queryout) pour exporter ces données ..... ou est-ce le seul défi technique ?

merci

Aucun problème de technique, j'aimerai bien le faire, mais c'est ai boulot et je n'ai l'accès qu'en lecture, je n'ai pas le droit de créer quoi que ce soit sur l'instance SQL...
(eh oui, gros système, des tas de règles en place, mais on te demandera quand même toujours de trouver une autre solution, malgré tous les bâtons qu'on te met dans les roues :))

EDIT: Ceci dit, SQLPro, tu ne réponds pas à ma question : est-ce que BCP peut prendre un fichier en paramètre qui contient un script (assez long) de calcul pour les données à exporter ?

Citation:

---

Envoyé par Laewella

Aucun problème de technique, j'aimerai bien le faire, mais c'est ai boulot et je n'ai l'accès qu'en lecture, je n'ai pas le droit de créer quoi que ce soit sur l'instance SQL...

---

Vous n'avez pas besoin de créer quoi que ce soit sur le serveur. BCP et SQLcmd sont deux exécutables en ligne de commande très similaire :
- BCP sert à l'import export (SELECT / INSERT)
- SQLcmd sert à exécuter des requêtes y compris de mise à jour de données ou création d'objet (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP....)

Citation:

---

Envoyé par Laewella

EDIT: Ceci dit, SQLPro, tu ne réponds pas à ma question : est-ce que BCP peut prendre un fichier en paramètre qui contient un script (assez long) de calcul pour les données à exporter ?

---

Non, car en matière d'export de données par exemple chaque requête aura des colonnes différentes donc une génération de fichier différent spécifique à chaque requête.
Mais rien ne vous interdit de créer une fichier de commande comportant de multiples lancement de commande BCP (ce que tout le monde fait, par exemple pour charger une base avec des données initiales).

A +

Sauf que dans mon cas, ce n'est pas juste un export par SELECT que je dois faire, sinon j'utiliserai BCP. Les données ne sont pas toutes prêtes sur l'instance SQL, je ne peux donc pas les "exporter" comme ça en une instruction.

Je récupère des données (dans plusieurs bases de l'instance SQL), que j'agrège en une seule table temporaire, sur laquelle j'effectue un SELECT à la fin de mon script pour récupérer les données que je viens de calculer. Je ne vois pas bien comment je pourrais faire ce genre d'opération avec BCP. J'ai dû loupé quelque chose dans vos explications...

tu as tout de même le droit de créer dropper une vue dans tempdb ?

Code:

---

1 2 3 4

use tempdb go create view mavue as select cols from mabase.dbo.table go

---

ensuite

Code:

---

bcp 'select cols from tempdb..mavue' out fichier.out ......

---

non ?

Ben limite je pourrai peut être créer la vue (faudrait que je demande) mais "mabase.dbo.TABLE" justement, j'ai pas...

J'ai un script SQL dans lequel je commence par faire CREATE TABLE #TABLE ( ... )
Puis je fais des calculs à coup de INSERT, UPDATE et DELETE dans #TABLE
Puis je fais un SELECT * FROM #TABLE
Et je finis par un DROP TABLE #TABLE

Et je fais du coup tout ça en une commande avec SQLCmd en lui filant moi fichier de script en paramètre...


Par contre, si ça marchait, si je crée une vue dans tempDB, c'est quoi sa durée de vie ? Elle reste ? Elle est purgée au bout d'un moment ? Si oui, est-ce que je n'ai pas le risque d'arriver avec mon BCP et de ne plus trouver la vue ?

Citation:

---

Puis je fais des calculs à coup de INSERT, UPDATE et DELETE dans #TABLE

---

Ah ok, comme quoi c'est important de bien expliquer ;)

En effet dans ce cas-là, tu peux créer une table tempo "persistante". A chaque exec du script tu testes si la table existe, tu la droppes et tu la crées à nouveau.

Code:

---

1 2 3 4 5 6

if exists (select ....) drop table ##table create ##TABLE insert/update/delete ##TABLE   bcp 'select cols from tempdb..TABLE' out fichier.out ......

---

et tu n'a pas besoin de vue.

Citation:

---

Envoyé par kagemaru

Ah ok, comme quoi c'est important de bien expliquer ;)

---

Ben j'croyais l'avoir fait :p Mais bon, pas toujours évident de se comprendre ;)

Citation:

---

Envoyé par kagemaru

En effet dans ce cas-là, tu peux créer une table tempo "persistante". A chaque exec du script tu testes si la table existe, tu la droppes et tu la crées à nouveau.

---

Pas bête comme idée, je savais pas que ce genre de table existait ! J'essayerai de voir si ça passe (vu les mecs qui décident de ce qu'on a le droit et ce qu'on a pas le droit, j'suis pas sûre !)

Merci en tout cas pour avoir fait l'effort de me comprendre ;)

Finalement, je dirais que ce problème d'encodage est moins critique que je ne le pensais : les données que je remonte où il pourrait éventuellement y avoir des caractères accentués représentent des noms de bases ou de jobs SQL, et même si c'est possible au niveau SQL Server, je pense que notre norme interne le déconseille fortement !


EDIT : Par contre, dans les MSDN, je lis ça :

Citation:

---

En revanche, le nom des tables temporaires globales commence par deux signes dièse (##) ; ces tables sont visibles à tout utilisateur après avoir été créées et ne sont supprimées qu'une fois que l'ensemble des utilisateurs ayant fait référence à la table se sont déconnectés de l'instance de SQL Server.

---

dans l'explication sur les "Notions de base sur la création et la modification d'une table".

Est-ce que ça ne veut pas dire que ma table temporaire globale va être supprimée lorsque SQLCMD aurait terminé son exécution (puisque tous les utilisateurs ayant référencé la table, à savoir juste moi, seront déconnectés) ? Du coup, quand j'arriverai avec BCP, il y a des risques qu'elle ne soit plus là ?