Insert depuis des csv sans bulkcopy

Salut à tous,

D'abords plantons le décor : SQLServeur 2008 R2, un petit utilitaire qui prépare des bases client. Dans le processus de préparation, il y a une phase d'import d'une 50ène de fichiers plats disons csv pour faire simple (c'est pas du "vrai" csv, mais c'est le même principe).
Les fichiers se trouveront normalement dans un dossier du serveur SQLServer. C'est pas une obligation à l'heure actuelle, mais une forte recommandation, ça pourra le devenir si c'est nécessaire. La seule obligation est que les fichiers soient accessibles sur le réseau par le moteur SQL.

L'utilitaire est utilisé en local sur le poste des utilisateurs, plusieurs utilisateurs simultanément. L'utilitaire est développé en .Net et actuellement l'import des fichiers est réalisé par la méthode .Net SQLBulkCopy.
Sur le réseau local tout marche bien

Maintenant, le problème :
Bientôt, 10% environ des utilisateurs, peut-être plus à terme, seront localisés sur un site distant, connexion au siège via internet et vpn (je suis moi-même sur ce site distant)
Avec cette méthode de SqlBulkCopy, les temps d'intégration des dits-fichiers se trouve multiplié pas 15 à 20, ce qui n'est pas acceptable.
Avec une analyse rapide, j'ai l'impression que via SqlBulkcopy, chaque fichier est d'abords rapatrié en local sur la machine du site distant avant d'être renvoyé sous forme de requête (je pense) au serveur SQL.
il faudrait donc que je vire le SqlBulkCopy et que je le remplace par autre chose
A noter que pour le reste des traitements, même faisant intervenir SqlServer, il n'est pas relevé de différences notables entre une utilisation sur le réseau local ou depuis le site distant

Ce que je cherche :
Il me semble me rappeler avoir déjà effectuer ce genre d'insert à distance, il y a une bonne 10ènes d'années directement via une requête SQL, fichiers sur le serveur SQL distant, requête exécutée à distance via SSMS, le moteur se démerdait à récupérer les fichiers localement chez lui.
Mais je ne retrouve pas la syntaxe.

Rappel : fichiers présents sur le serveur SQL ou tout au moins accessible localement sur le réseau, fichier au format similaire au csv (délimiteur différent, ligne d’entête), les fichiers ne contiennent généralement pas toutes les colonnes de leur table correspondante (absence de la clé primaire notamment, auto-générée à l'insertion). On a déjà un fichier schéma pour l'ensemble des fichiers au format ini, compatible MS Jet 4.5
Commande envoyée depuis un exe lancé sur un poste d'un site distant

Si le fichier est localement présent sur le server sql, sqlbulkcopy rapatrie localement les données, je vous le confirme puisque vous pouvez utiliser sqlbulkcopy avec n'importe quelle source (même un simple objet en mémoire).

Le plus simple: créez une procédure stockée prenant en paramètre le chemin du fichier a importer et appelez la directement de votre code...

A l'intérieur de la procédure stockée utilisez le BULK INSERT en TSQL (https://docs.microsoft.com/fr-fr/sql...t-transact-sql)

Dans les grandes lignes:

Code:

---

1 2 3 4 5 6 7 8

BULK INSERT AdventureWorks2012.Sales.SalesOrderDetail FROM 'f:\orders\lineitem.tbl' WITH ( FIELDTERMINATOR =' |', ROWTERMINATOR =' |\n' );

---

salut,

Effectivement ce matin je suis parti sur cette piste, mais je rencontre, pour le moment, principalement, 2 problèmes.

1 - JE suis obligé de passer par un fichier schéma car mon fichier texte ne contient pas toutes les colonnes de la table, mais j'ai, malgré tout un décalage, la première colonne du fichier ne correspond pas à la première colonne de la table

2 - J'ai un problème avec les dates. Mes dates sont au format français, ça j'ai réglé avec set dateformat dmy, mais surtout les champs correspondant aux dates dans le fichier texte peuvent être vide. Cela me génère une erreur de conversion lors du bulkinsert malgré le fait d'avoir indiqué que les champs peuvent être null des 2 cotés dans le schéma, et de faire le bulk avec l'option KEEPNULLS

Dans ce cas j'ai plus simple: placez le code actuel sqlbulkcopy dans un web service héberge sur le même réseau que votre Server sql...

Côté client lourd appelez simplement le WS...