MSSQL ADO

Chce wykonac okolo 1000 SELECT, INSERT, CREATE na MSSQL przez C#.ADO
Mam pytanie czy lepiej wykonywac kazda komende kolejni :
foreach (string cmd in cmds)
{
command = connection.CreateCommand();
command.CommandText = cmd;
command.ExecuteNonQuery();
}

czy wrzucic wszystko do stringa cmd i wykonac

command = connection.CreateCommand();
foreach (string cmd in cmds)
{

                command.CommandText = command.CommandText+cmd;

}
command.ExecuteNonQuery();

Baza danych to MSSQL;

pozdrawiam
marcin

sugeruje po kolei, dzieki temu bedziesz mogl lepiej zapanowac nad bledami
kluczem jest wykonanie tego w ramach jednego polaczenia, bo nawiazanie polaczenia z baza jest dosc kosztowne, wiec jesli bedziesz otwieral/zamykal connection dla kazdego query, to troche poczekasz na rezultaty
oczywiscie jesli wstawiasz/modyfikujesz dane warto dokonac tego w transakcji, tak aby jesli czesci danych nie uda sie zmodyfikowac, zeby nie pozostawic jakis smieciowych powiazanych z nimi wstawionych wczesniej

jesli masz duzo danych do importu, sa specjale techniki do tego aby wykonac to wydajnie
bulk insert
mozna takze podpiac sie do roznych zrodel danych (m.in. do plikow excel, cvs), a nastepniw wykonywac na nich bardziej skomplikowane zapytania i przyspieszyc przenoszenie danych do bazy

kluczem jest wykonanie tego w ramach jednego polaczenia

Nie wiem co rozumiesz przez "1 połączenie" bo tutaj zarówno jeden jak i drugi pomysł będzie się opierał na jednym połączeniu z bazą danych.

Kwestia czy wykonać 1000 komend z .NET, czy jedną komendę a w niej - 1000 poleceń.

Drugi przypadek wydaje się bardziej optymalny, ale nigdy nie widziałem, aby ktoś potrzebował 1000 poleceń na ExecuteNonQuery :/

Wydaje mi sie, ze wykonanie jednej komendy odbedzie sie w jednej transakcji, podczas gdy wykonanie osobnych komend na pewno nie. Co tez da sie oczywiscie zalatwic. Wykonanie 1000 transakcji zamiast jednej bedzie na pewno wolniejsze.

Deti napisał(a)

kluczem jest wykonanie tego w ramach jednego polaczenia

Nie wiem co rozumiesz przez "1 połączenie" bo tutaj zarówno jeden jak i drugi pomysł będzie się opierał na jednym połączeniu z bazą danych.

chcialem zaznaczyc aby nie tworzyc osobnego connection dla kazdego zapytania, czy jakiejs grupy wykonywajej w ramach transakcji

nalezy tez zastanowic sie jakie grupy zapytan powinny byc w ramach tej samej transakcji, byc moze warto zadbac, aby czesc zapytan nie odbywala sie w transakcji (np. jakies selecty, aby nie blokowaly rekordow, zalezy oczywiscie od isolation level)

Wydaje mi sie, ze wykonanie jednej komendy odbedzie sie w jednej transakcji, podczas gdy wykonanie osobnych komend na pewno nie.

W obu z powyższych może albo nie być transakcji (operowanie na SqlConnection), albo być transakcja (operowanie na SqlTransaction) - więc jeśli chodzi o to, co autor wątku już napisał - nie ma w ogóle mowy o żadnej transakcji w obu przypadkach.