Discussion :

[Riki]

Bonjour à tous,

J'avais une petite question : est-il possible d'importer des données dans une base sql via bulk copy à partir d'un programme ? Par exemple, via un bout de code C#.
Je sais qu'il est possible de faire cela avec le framework 2.0 où un nouvel objet existe pour cela mais je me place dans le cas du framework 1.1

Mon but serait par exemple d'importer une datatable dans une db le plus rapidement possible et non via une grosse requête pleine de inserts.

Merci.

[WOLO Laurent]

A partir de ton datatable, tu génères des commandes insert en bloc de 100 ou 1000 bref ca ne dépend que de toi et par la suite tu les pompes vers la base de données : C'est ca l'objet de bulk insert ....
Tu pourras ajouter le mutitreading pour accelerer .

Bonne chance

[Riki]

Salut,

Que veux-tu dire par "pompe" vers la base de données ?
Je crée par exemple un grand string contenant 1000 requêtes séparées par des point-virgules et je l'éxécute d'un coup, simplement ?

C'est déjà ce que je fais mais quand on parle de bulk copy, on parle de copy par de bas niveau, si le bulk copy c'est juste ça, je ne vois pas en quoi ce serait bas niveau et bcp plus rapide.


Merci.

[WOLO Laurent]

C'est justement ca le bulk copy.
Il te suffit d'ajouter la gestion de l'execution asynchrone et tu viens de recréer le bulk copy !

Mais qu'est ce que tu appelles par copy bas niveau ?
Je te rappelle que ce n'est pas le client qui gère la manipulation des données d'un serveur en mode client/serveur, c'est le serveur lui même et tout le flux de données qui est reçu par le serveur est interpreter comme du texte pûr, alors ca ne sert à rien de te casser la tête.
Si néanmoin, vous avez des soucis d'optimisation, il vous faut créer une procédure stockée pour avoir quelque chose qui ressemble à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

	

	
Code  :
	
Sélectionner tout -
	Visualiser dans une fenêtre à part
	
123456789
 
exec maprocedure val1,val2,val3.....,valk
.
.
.
.
.
 
exec maprocedure val1,val2,val3.....,valk

[Riki]

Salut,

Après petite recherche, il s'avère en fait que le bulk copy permet en fait de copier directement une datatable dans une table de la base et ce sans créer de requête sql !!
Il suffit plus ou moins de faire un mapping des colonnes et de faire un copy().
A mon avis, c'est ce qu'on entend par "bas niveau" (moi-même je ne comprenais pas exactement ce que ce terme voulait dire).

Donc pour être plus clair, la datatable serait par exemple obtenue via une requête sql faisant en une recherche dans une DB A et ensuite, si le client le désire, il peut cliquer sur "sauver" et la datatable est enregistrée dans sa base locale.

C'est ce que semble permettre le nouvel objet sqlbulkcopy de l'asp.net 2.0.

[WOLO Laurent]

Non, c'est faux !
En fait, vous ne pouvez pas acceder une base de donnée client:serveur sans requête SQL !
Quelle abération ?!
Toutes ces fonctionalités sont wrappée par la classe, et c'est comme cela que ca marche !
Je vais inviter des experts SQL à cette discution svp !

[Riki]

Hop, voilà le lien où j'ai trouvé ce que je raconte :

http://www.codeproject.com/cs/database/SqlBulkCopy.asp


Je me permets de rajouter ce commentaire de la part d'un gars de chez microsoft :

While I am talking about SqlBulkCopy again, I should mention Pablo Castro's, the Program Manager for the ADO.NET Team at Microsoft, great explanation as to why SqlBulkCopy is faster than using normal insert commands:

"There are a number of reasons why bulk-copy is faster. Here is a summary:

No per-row statement execution. When you do multiple inserts without bulk-copy, each insert is a statement in itself (regardless of whether it's batched together with other statements). With bulk-copy, we don't incur the cost of executing a statement for each row, the whole copy operation is a single thing.
No multiple network round-trips. Once the bulk-insert operation is setup, we send rows from the client to the server continously, without going back-and-forth over the wire.
Server storage engine also can greatly optimize how rows are inserted when performing a bulk-copy operation. How much can be optimized depends a lot on the recovery model the tarder database is set to; in "simple" and "bulk logged" the overhead of logging is greatly reduced during bulk-copy operations, helping a lot with performance.

(source : http://davidhayden.com/blog/dave/arc...3/08/2877.aspx)

Je pense vraiment qu'il ne s'agit pas de simples requêtes sql en background.

[Mose]

Non, c'est faux !
En fait, vous ne pouvez pas acceder une base de donnée client:serveur sans requête SQL !
Quelle abération ?!
Toutes ces fonctionalités sont wrappée par la classe, et c'est comme cela que ca marche !
Je vais inviter des experts SQL à cette discution svp !

Si si.
Y'a une fonction en ligne de commande, fournie avec SQL Server 2000 (pour 2005 je sais pas) qui faisait ça. bcopy je crois.
Très pratique pour faire de l'export/import.
Mais très dangeureux et dramatique en cas de changement de collation (langue)

[WOLO Laurent]

Hop, voilà le lien où j'ai trouvé ce que je raconte :

No multiple network round-trips. Once the bulk-insert operation is setup, we send rows from the client to the server continously, without going back-and-forth over the wire.
Server storage engine also can greatly optimize how rows are inserted when performing a bulk-copy operation. How much can be optimized depends a lot on the recovery model the tarder database is set to; in "simple" and "bulk logged" the overhead of logging is greatly reduced during bulk-copy operations, helping a lot with performance.
[/I]
(source : http://davidhayden.com/blog/dave/arc...3/08/2877.aspx)

Je pense vraiment qu'il ne s'agit pas de simples requêtes sql en background.

J'insiste, qu'en terme d'optimisation des performances, il serait bête d'envoyer des données d'une table de 2000000 de lignes à un serveur sans pouvoir les segmenter !
Il est clair qu'il ne sagit pas des insert ligne-par-ligne mais des insert en bloc de 1000 lignes par exemple mais en plusieurs bloc par exemple. Et ce sont ces fonctionalités qui sont wrappées dans cette nouvelle classe du Framework 2.0.
Mais puisse que vous insistez, je vais inviter des Experts et faire des recherches plus poussées.

[busymante]

Si si.
Y'a une fonction en ligne de commande, fournie avec SQL Server 2000 (pour 2005 je sais pas) qui faisait ça. bcopy je crois.
Très pratique pour faire de l'export/import.
Mais très dangeureux et dramatique en cas de changement de collation (langue)

Parlez-vous de la commande bcp ? Si c'est le cas, elle n'est exécutable qu'à partir du server et non du poste client.

Le plus simple semble en effet de créer une procédure stockée contenant un BULK INSERT que l'on appellera à partir du code.

Pour ma part, je cherche un moyen d'intégrer des variables à la place du nom de la table et des noms de fichiers, si quelqu'un a une idée elle serait bienvenue...

[CetTer]

Je me permets d'intervenir dans la discussion en retard:
Avec SQL Server 2000 (je ne sais pas ce qu'il en est de 2005), il n'est pas forcément nécessaire de faire du SQL pour importer des données dans SQL Server.
Il me semble que la principale différence entre Bulk Insert/BCP et une requête SQL est que l'on peut empêcher le log en procédany bcp et Bulk Insert (ce qui peut être pratique pour l'importation de gros recordset), tandis qu'il n'est pas possible de désactiver le log lorsqu'il s'agit de requêtes SQL.

Je ne pense pas qu'une commande BULK INSERT est retraduite en SQL, je pense qu'elle est plutôt retraduite dans un script VBScript ou VB6.0 que SQL Server peut exécuter via le DTS (Data Transformation service).

La tâche Bulk Insert (tout comme les requête SQL d'ailleurs) peut en effet être paramêtrée dans un script écrit en VB6.0 et VB Script (rapide et relativement facile à porter en .Net, mais peu portable car il demande l'importation d'une DLL COM de SQL Server) que le "Data Transformation Service" (de SQL Server 2000) génère automatiquement et que l'on peut exécuter comme tâche planifiée ou intégrer dans une application.

Je crois que toutes ces fonctionnalités sont en effet de facto liées au serveur (peut-être qu'il est possible de copier la librairie COM du DTS sur un client, mais celà rend vraiment l'application peu portable, et celà risdque de poser problème avec les dépendances au niveau des tâches planifiées)