Różnica między Parameters.Add (string, object) i Parameters.AddWithValue


Przeczytałem dokumentację MSDN i przykłady

tutaj
http://msdn.microsoft.com/en-u ... .aspx
i znam poprawną składnię wywołania
Parameters.Add
:
command.Parameters.Add("@ID", SqlDbType.Int);
command.Parameters["@ID"].Value = customerID;

Gdzie musisz określić nazwę parametru, a następnie
SqlDbType
ORAZ wartość z
.Value
.
Teraz poprawna składnia do wywołania
Parameters.AddWithValue
to:
command.Parameters.AddWithValue("@demographics", demoXml);

Jedna linia i pomiń część
Type
.
Moje pytanie brzmi: jak to się dzieje, kiedy robię to w ten sposób,
command.Parameters.Add("@demographics", demoXml);
// .Add method with .AddWithValue syntax

Nie otrzymuję żadnych błędów kompilacji i, co dziwne, czy wszystko wydaje się działać poprawnie, gdy kod jest wykonywany?
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nie ma różnicy pod względem funkcjonalności. W rzeczywistości obaj to robią:
return this.Add(new SqlParameter(parameterName, value));

Powodem, dla którego porzucili stary na rzecz
AddWithValue
, jest dodanie większej przejrzystości, a także dlatego, że drugi parametr to
object
, co nie czyni go od razu oczywistym niektórym osobom, które wywoływały przeciążenie
Add
, co spowodowało zupełnie inne zachowanie.
Spójrz na ten przykład:
SqlCommand command = new SqlCommand();
command.Parameters.Add("@name", 0);

Na pierwszy rzut oka wygląda na to, że wywołuje przeciążenie
Add (nazwa ciągu, wartość obiektu)
.

ale tak nie jest
... Wywołuje przeciążenie
Add (nazwa ciągu, typ SqlDbType)
! Dzieje się tak, ponieważ 0 jest niejawnie konwertowane na typy wyliczeniowe. Więc te dwie linijki:
command.Parameters.Add("@name", 0);

i
command.Parameters.Add("@name", 1);

W rzeczywistości powoduje to wywołanie dwóch różnych metod.
1
nie jest niejawnie konwertowany na wyliczenie, więc wybiera przeciążenie
object
. Z
0
wybiera przeciążenie wyliczenia.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Różnica polega na niejawnej konwersji podczas korzystania z AddWithValue. Jeśli wiesz, że Twoje wykonywalne zapytanie SQL (procedura składowana) akceptuje wartość typu int, nvarchar itp., Nie ma powodu, aby ponownie deklarować ją w kodzie.
W przypadku złożonych scenariuszy, takich jak (np. DateTime, float), prawdopodobnie użyję Add, ponieważ jest bardziej wyraźny, ale AddWithValue dla bardziej prostych scenariuszy, takich jak (Int to Int).
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Bez jawnego określenia typu, jak w
command.Parameters.Add ("@ ID", SqlDbType.Int);
, spróbuje niejawnie przekonwertować dane wejściowe na to, czego oczekuje.
Wadą tego jest to, że niejawna konwersja może nie być najbardziej optymalną z konwersji i może prowadzić do słabej wydajności.
Tutaj jest dyskusja na ten temat:

http://forums.asp.net/t/1200255. aspx/1
http://forums.asp.net/t/1200255.aspx/1
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Kiedy używamy
CommandObj.Parameter.Add ()
, przyjmuje on 2 parametry, pierwszy to parametr procedury, a drugi to jego typ danych, podczas gdy
.AddWithValue ()
przyjmuje 2 parametry, pierwszy to parametr procedury, a drugi to zmienna danych
CommandObj.Parameter.Add("@ID",SqlDbType.Int).Value=textBox1.Text;

dla
.AddWithValue
CommandObj.Parameter.AddWitheValue("@ID",textBox1.Text);

gdzie
ID
to parametr procedury składowanej, której typem danych jest
Int
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nie ma różnicy pod względem funkcjonalności
Metoda
addwithvalue
akceptuje obiekt jako wartość. Nie ma sprawdzania typu danych typu. Może to potencjalnie prowadzić do błędu, jeśli typ danych nie jest zgodny z tabelą SQL. Metoda
add
wymaga najpierw określenia typu bazy danych. Pomaga to zredukować te błędy.

Po więcej informacji,

proszę kliknąć tutaj
https://jwcooney.com/2012/09/1 ... alue/

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się