J'ai récemment effectué une mise à niveau vers SQL2012 et j'utilise Management Studio. Une de mes colonnes dans la base de données a un CHAR(13) + CHAR(10)
qui y est stocké.
Lorsque j'utilisais SQL Server 2008, cette opération se copiait et se collait parfaitement dans Excel. Aujourd'hui, cependant, copier et coller les mêmes données crée une nouvelle ligne/un retour chariot dans les données que j'ai dans Excel.
Y a-t-il un paramètre que j'ai manqué dans SQL2012 pour résoudre ce problème ? Je ne veux pas simplement REPLACE(CHAR(13) + CHAR(10))
sur chaque sélection de base de données, car je devrais passer de l'utilisation de SELECT *
pour définir chaque colonne individuelle.
0 votes
Comment copier et coller, en sélectionnant simplement les résultats de la requête, ctrl+c, ctrl+V ?
0 votes
J'ai reproduit l'erreur avec Management Studio 2008 (pas de nouvelles lignes) et Management Studio 2012 (nouvelles lignes), en utilisant la requête
select top 10 char(10) + char(13) as [struff] from dbo.tbEntries
2 votes
Vous dites donc que vous ne voulez pas que le retour chariot apparaisse dans Excel, bien qu'il soit dans les données ? Si c'est le cas, il semble qu'ils aient simplement corrigé un bug de 2008 à 2012... Si c'est la façon dont vos données sont représentées, vous devez les manipuler pour obtenir le format que vous souhaitez.
0 votes
@Derek Kromm c'est exactement ce que je dis. Je vais essayer d'installer à nouveau le gestionnaire de serveur 2008 et voir si le problème persiste. Si c'est le cas, il s'agit probablement d'un problème avec Excel ou autre.
0 votes
Ça craint. J'étais capable de copier des milliers de lignes, avec et sans retours chariot, depuis SSMS 2008 et de les coller dans Excel parfaitement. Maintenant que j'ai effectué la mise à niveau vers SSMS 2012, c'est complètement raté. SSMS 2012 est très défectueux et l'option d'exportation vers CSV est inutile dans les deux versions, car elle ne respecte absolument pas les spécifications du format de fichier CSV.
4 votes
Le format CSV est très spécifique et tient compte de tous les caractères possibles en exigeant que les chaînes de caractères comportant des guillemets, des virgules ou des sauts de ligne soient entourées de guillemets doubles, les guillemets doubles réels étant doublés. SSMS 2012 (et 2008) jette simplement tout dans un fichier et colle des virgules entre les cellules, ce qui est tout à fait négligé et inutile. Quel que soit le format que 2012 met dans le presse-papiers, il est très très mauvais, contrairement à SSMS 2008.
7 votes
Il existe une option sous Outils > Options > Résultats de la requête > Résultats vers la grille > "Citer les chaînes contenant des séparateurs de liste lors de l'enregistrement des résultats .csv". Il est absurde que cette option ne soit pas cochée par défaut, ce qui constitue une violation complète du format de fichier CSV.
3 votes
LOL, encore pire... avec cette option cochée, au lieu de transformer les guillemets doubles en paires de guillemets doubles comme le dit la spécification CSV, il convertit les guillemets doubles en deux guillemets simples. C'est tout à fait, complètement inacceptable.
0 votes
" RFC 4180 : Chaque ligne, ou tuple, est séparée par un saut de ligne, et la dernière ligne peut être terminée par un saut de ligne. Chaque ligne doit contenir le même nombre de champs, qui sont séparés par un seul caractère, généralement une virgule. Les champs peuvent être encadrés par des guillemets. Dans ce cas, les champs peuvent contenir des virgules ou des caractères de saut de ligne. Ils peuvent également contenir des caractères entre guillemets s'ils sont "échappés" par un deuxième caractère entre guillemets adjacent. Les valeurs de données nulles sont indiquées par deux délimiteurs sur une ligne, sans aucune donnée entre eux."
4 votes
Quelqu'un a déjà déposé un rapport de bogue à ce sujet ici : connect.microsoft.com/SQLServer/feedback/details/783274/ Il s'agit certainement d'un bug de SSMS 2012. J'ai ajouté une solution de contournement consistant à utiliser SSMS 2008 et je me suis plaint de la mauvaise implémentation CSV.
1 votes
Microsoft a orienté les utilisateurs vers ce problème de connexion : connect.microsoft.com/SQLServer/feedback/details/735714 Il est répertorié comme un bogue connu "actif" pour le moment et MS a publié une solution de contournement qui consiste essentiellement à remplacer CHAR(10) et CHAR(13) par des chaînes vides. Cela fonctionnera mais ce n'est pas la solution que nous recherchions tous.
0 votes
Ce fil de discussion a beaucoup d'abonnés. Toute personne rencontrant ce problème devrait aller ici et voter pour que Microsoft publie un correctif pour ce problème : connect.microsoft.com/SQLServer/feedback/details/735714
0 votes
J'ai voté pour cela - si ennuyeux...
0 votes
Ugh, c'est affreux. Je suis sous une énorme pression et je n'ai pas le temps pour ça.
0 votes
Cet article pourrait vous aider : mssqltips.com/sqlservertip/3416/