Jest to całkowicie przewidywalne i oczekiwane ze względu na Pierwszeństwo typów danych
W tym celu kolumna interfejsu użytkownika zostanie zmieniona na dziesiętną(25,0)
where UI = 2011040773395012950010370
Ten jest prawie poprawny. Prawa strona to varchar i zmienia się na nvarchar
where UI = '2011040773395012950010370'
To jest naprawdę poprawna wersja, w której oba typy są takie same
where UI = N'2011040773395012950010370'
Pojawią się błędy, ponieważ kolumna interfejsu użytkownika zawiera teraz wartość, która nie jest przesyłana do postaci dziesiętnej (25,0).
Kilka niepowiązanych notatek:
- jeśli masz indeks w kolumnie interfejsu użytkownika, zostanie on zignorowany w pierwszej wersji z powodu wymaganego niejawnego CAST
- Czy potrzebujesz Unicode do przechowywania cyfr? Istnieje poważne obciążenie z typami danych Unicode w pamięci i wydajności
- dlaczego nie użyć
char(25)lubnchar(25)czy wartości mają zawsze stałą długość? Twoje zapytania używają za dużo pamięć jako optymalizator przyjmuje średnią długość 128 znaków na podstawienvarchar(256)
Edytuj, po komentarzu
Nie zakładaj „dlaczego to czasami działa”, gdy nie wiesz że to działa
Przykłady:
- Wartość mogła zostać usunięta, a następnie dodana później
- Klauzula TOP lub SET ROWCOUNT może oznaczać, że nie osiągnięto naruszającej wartości
- Zapytanie nigdy nie zostało uruchomione, więc nie mogło się nie powieść
- Błąd jest po cichu ignorowany przez inny kod?
Edytuj 2, aby uzyskać większą przejrzystość
Czat
PLN:
Losowo:
PLN
Jak wspomina Tao , ważne jest, aby zrozumieć, że inne niepowiązane zapytanie może przerwać zapytanie, nawet jeśli to jest w porządku.
