Bonsoir, je réponds un peu tard, désolé.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
SQLpro
Ha bon... Montrez moi votre référence ! EN fait n'importe quel délimitation peut être prise en charge par le BULK INSERT, il suffit d'indiquer le bon FILEDTERMINATOR qui est la virgule et le bon ROWTERMINATOR qui est \n !
Pourtant, c'est bien écrit dans la documentation en ligne de la commande BULK INSERT de SQL Server 2014 :
https://msdn.microsoft.com/fr-fr/lib...=sql.120).aspx
Interopérabilité
Importation des données d'un fichier CSV
Les fichiers de valeurs séparées par des virgules (CSV, Comma-Separated Value) ne sont pas pris en charge par les opérations d'importation en bloc SQL Server. Toutefois, dans certains cas, un fichier CSV peut être utilisé comme fichier de données pour une importation en bloc de données dans SQL Server. Pour plus d'informations sur les conditions requises pour importer les données d'un fichier CSV, consultez Préparer des données en vue d'une exportation ou d'une importation en bloc (SQL Server).
Partant de là, j'ai hésité à utiliser cette méthode pour charger du CSV...
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
SQLpro
CSV concerne du texte.... S'il y a des données autres elles doivent être stockées sous forme d'octets, les octets représentant du texte dans un fichier texte... Aucune difficulté là dedans, sauf si par malheur vous avez un octet à 44 ! (virgule)
CSV, c'est "Coma Separated Values", sous forme d'un fichier TEXTE. Par définition, l'ensemble des VALEURS présentes dans le document sont forcément sous une forme textuelle et non binaire.
Ainsi, si j'ai le nombre "trente six", j'aurai dans mon fichier "36" et non "*00100100" en binaire (ou "$" une fois converti en binaire et affiché sous forme de texte ASCII).
Par conséquent, si dans mon fichier j'ai des valeurs numériques (ou date, etc.) elles seront sérialisées sous forme de texte en utilisant une locale déterminée : BULK INSERT ne saura visiblement pas relire ces informations autrement que sous forme de chaînes de caractères, obligeant à refaire des traitements lourds pour les transformer en données typées.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
SQLpro
Là encore vous vous trompez, l'INSERT vectoriel est supporté mais limité (je crois à 10000 lignes)...
Alors ça, ça m'intéresse. Avez-vous un exemple de syntaxe ?
J'entends par insertion multiple à l'aide de l'instruction "insert values" une syntaxe du même style que celle de MySQL :
INSERT INTO matable (id, label) values (1, 'toto'), (2, 'titi'), (3, 'tata');
Ce qui permettrait d'insérer en lot plusieurs lignes sans devoir passer par des objets temporaires (CTE, sous-requête, etc.)
Je sais qu'en utilisant C# par exemple, on peut stocker par exemple un int[] dans un varbinary, mais on est loin de ce que je recherche.
Autre solution, faire en langage CLR une procédure qui prend un varchar(max) en paramètre, puis effectue les INSERT en passant par la connexion de contexte... Certainement à peine plus rapide que si on lance des lots d'INSERT, mais moins souple.
![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
SQLpro
Ca c'est la seule chose importante de votre demande.... Dans ce cas
1) insérer dans une table temporaire déstructurée (toutes les colonnes en VARCHAR ou NVARCHAR)
2) corriger les éventuelles anomalies
3) reporter l'insertion dans la table définitive
A +
Ok, mais moi je cherche à optimiser l'étape 1.
J'ai par exemple un fichier de 10 000 000 lignes, et je souhaite qu'il soit inséré en moins de 1 minute.
=> On peut aisément faire un SELECT INTO de 10 000 000 lignes à partir d'une autre table dans ce délai, donc je cherche une solution pour faire la même chose. Jusqu'à présent, j'en suis plutôt à 100 000 lignes par minute, ce qui est loin d'être satisfaisant...
Partager