Export des données sur un server sql en excel avec l'utilitaire sqlcmd

Bonjours à toutes et à tous,

J'interroge une base de données qui se trouve sur un server sql, en utilisant l'utilitaire sqlcmd. Pour cela, j'aurais deux questions s'ils vous plaît !

1^re question : comment faire pour exporter le résultat de mes requêtes en excel ? Sachant que, j'arrive à exporter les données en fichier.txt grâce à la commande "> resultat.txt". Par contre, quand j'essaye avec "resultat.csv" par exemple, mon fichier csv n'affiche pas toutes les données voir aucune.

2^e question : j'ai quelques requêtes qui ne s'exécutent pas sous sqlcmd, mais qui s'exécutent parfaitement sur sql developer par exemple. Quelqu'un aurait une explication pour ça ?

Merci.

SQL developper est un produit Oracle. sqlcmd.exe est un outil Microsoft SQL Server....

Précisez votre question et donnez des exemples de ce qui ne vas pas... (et les messages d'erreur s'il y en a)

A +

Bonjour,

Je vous remercie pour votre retour !

Je reformule espérant être plus claire ! J'interroge une base de données avec le CMD automatiquement en créant des fichiers Batch qui exécutent des requêtes sql et qui m'exportent le résultat sous un format txt (un format qui ne me convient pas à long terme), lorsque j'essaye d'exporter avec le même fichier batch les données en csv par exemple (le résultat ne s'affiche pas correctement).

Ça, c'était ma 1re question (existe-t-il une manipulation, ou un moyen plus efficace pour exporter correctement les données sachant que la taille de mes fichiers pourraient être assez conséquente > 500 Mo ?).

Concernant le sql developer, je l'utilise pour écrire mes requêtes sql et les tester. (Oui, sql developer est un outil Oracle. Mais on peut se connecter avec, sur un server sql, il suffit d'utiliser un pilote JDBC.).

Et là, arrive ma 2emme question : est ce que le sqlcmd est limité dans la syntaxe sql, puisque les mêmes requêtes sql que j'exécute sur le sql developer ne s'exécutent plus sur le cmd.Pièce jointe 631200

Merci pour le temps que vous me consacrez :)

Citation:

---

Envoyé par adeloub

Et là, arrive ma 2emme question : est ce que le sqlcmd est limité dans la syntaxe sql, puisque les mêmes requêtes sql que j'exécute sur le sql developer ne s'exécutent plus sur le cmd.

---

Si on avait la requête, on pourrait avoir une idée...

Vous utilisez un produit Oracle... Postez dans un forum Oracle ! Déjà le simple délimiteur d'identifiants SQL n'est pas le bon...

A +

Je n'utilise pas un produit oracle! J'utilise l'utilitaire sqlcmd. le sql developer je l'utilise, pas plus, comme un éditeur de code pour voir le résultat de mes requêtes avant de les mettrent dans mon fichier batch. J'ai juste constaté que des bout de code fonctionnent correctement sur le sql developer, et que dans le fichier batch je reçois un message d'erreur.

À moins que la syntaxe change ? Je n'arrive pas à comprendre pourquoi le message d'erreur n'est pas aussi présent lorsque j'exécute sur sql developer !

Je vous mets ici le code et le message d'erreur :Pièce jointe 631265Pièce jointe 631266

Le " n'est autorisé que pour les alias de colonne :

Code:

---

1 2	select id "ma super colonne de la mort" from table

---

Le ' n'est autorisé que pour délimiter des chaînes de caractère :

Code:

---

select 'ma super valeur' "ma super colonne de la mort"

---

La plupart du temps, il est totalement inutile d'échapper le nom des objets, c'est une très mauvaise manie introduite par les ORM...

Code:

---

1 2 3

select alias.id monid from matable alias where alias.name = 'test'

---

Sinon, avec SQL Server, on échappe les noms des objets avec des crochets :

Code:

---

1 2 3

select [mon alias à la con].[ma colonne à la con] "mon titre à la con" from [ma table à la con] [mon alias à la con] where [mon alias à la con].[mon autre colonne à la con] = 'test à la con';

---

-- Edit : ça doit faire 20 ans que j'ai pas vu de AS pour aliaser une colonne ou une table. Trop de verbe tue le verbe. Gardez le AS pour aliaser les CTE et les sous-requêtes.
-- Edit 2 : et faut choisir entre "LEFT OUTER JOIN" et "LEFT JOIN". Perso, même si trop de verbe tue le verbe, je préfère garder "OUTER" systématiquement : à la relecture on est bien sûr qu'on fait une jointure ouverte et pas un INNER dont on a oublié le nom.

Je vous remercie pour vos explications ! J'en prendrais compte :)

Citation:

---

Envoyé par StringBuilder

Le " n'est autorisé que pour les alias de colonne

---

La double quote, dans le standard SQL, sert à délimiter un nom d'objet (colonne, table, trigger, udf...) quand celui-ci est un nom réservé SQL
Par exemple si je décide d'appeler une colonne "time", "null", "table" ou encore "select" :aie:
Nommer ainsi un objet est une très mauvaise idée, ça ne présente aucun intérêt et complique inutilement les requêtes.

Il faut noter que si une table comporte une colonne nommée "toto"
tester WHERE ma_colonne="toto" revient à vérifier l'égalité de contenu entre la colonne ma_colonne et la colonne "toto" et non pas entre ma_colonne et la chaîne de caractères 'toto'.
Attention donc aux confusions.
À noter également que MySQL autorise les doubles quotes comme délimiteur de chaînes de caractères (en plus des simples quotes); ce qui est d'autant plus dangereux dans le cas que je viens de citer : WHERE ma_colonne="toto"...

Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

create table t1 ( c1 integer not null primary key , "null" char(4) not null , toto char(4) ) ; insert into t1 (c1, "null", toto) values (1, 'toto', 'AZ') , (2, 'titi', 'titi') , (3, 'tata', 'TY') ; select * from t1 where "null"= "toto" ; select * from t1 where "null"= 'toto'

---

Notez le résultat différent des deux requêtes ici sous SQL-server :

c1	null	toto
2	titi	titi

c1	null	toto
1	toto	AZ