Jak uniemożliwić dyskretne obcięcie wejściowych danych przechowywanych w bazie?

Question

Używamy standardowych klas System.Data, i DbCommand, aby połączyć się z SQL Server z C#, a my mamy wiele procedur przechowywanych, które przyjmują parametry VARCHAR lub NVARCHAR jako dane wejściowe. Okazało się, że ani SQL Server, ani nasza aplikacja C# nie zgłasza żadnego rodzaju błędu lub ostrzeżenia, gdy łańcuch o długości większej niż maksymalna długość parametru jest przekazywany jako wartość tego parametru. Zamiast tego wartość jest bezgłośnie skracana do maksymalnej długości parametru.

Tak więc, na przykład, jeśli wejście procedura przechowywana jest typu VARCHAR(10) i mijamy w 'U R PRETTY STUPID', procedura przechowywana odbiera dane wejściowe jako 'U R PRETTY', co jest bardzo miłe, ale zupełnie nie to, co chciał powiedzieć.

Co zrobiłem w przeszłości, aby wykryć te skracania i co to jest others have likewise suggested, to aby długość wprowadzanego parametru była większa o jeden znak niż jest to wymagane, a następnie sprawdzić, czy długość wejścia jest równa tej nowej maksymalnej długości . W powyższym przykładzie moje dane wejściowe miałyby postać VARCHAR(11), a ja sprawdziłbym, czy dane wejściowe mają długość 11. Każde wejście o długości 11 lub więcej zostanie przechwycone przez ten test. To działa, ale czuje się źle. W idealnym przypadku warstwa dostępu do danych automatycznie wykryłaby te problemy.

Czy istnieje lepszy sposób na wykrycie, że dane wejściowe procedury składowanej są dłuższe niż dozwolone? Czy nie powinien już być znany limit długości wejściowej?

Co się tyczy ciekawości, co jest odpowiedzialne za ciche obcinanie naszych danych wejściowych?

Answer 1

Użyj VARCHAR(8000), NVARCHAR(4000) lub nawet N/VARCHAR(MAX) dla wszystkich zmiennych i parametrów. W ten sposób nie musisz martwić się obcięciem przy przypisywaniu @ zmiennych i parametrów @. Truncation może wystąpić przy zapisie danych rzeczywistych (wstawić lub zaktualizować), ale to nie jest ciche, spowoduje błąd, a dowiesz się o tym. Dodatkową korzyścią jest to, że kod procedury przechowywanej nie musi być zmieniany wraz ze zmianami schematu (zmiana długości kolumny, kod jest nadal ważny). A także masz lepsze zachowanie pamięci podręcznej planu dzięki użyciu stałych długości parametrów, patrz How Data Access Code Affects Database Performance.

Należy pamiętać, że istnieje nieznaczne obniżenie wydajności dla używania typów MAX dla @ zmiennych/parametrów, patrz Performance comparison of varchar(max) vs. varchar(N).