- ustawień bazy - jeśli parametr NLS_LENGTH_SEMANTICS ma na poziomie bazy wartość CHAR, i nie jest przesłaniany w sesjach, to problem nie występuje, jeśli ma wartość BYTE to jest to źródło wielu dokuczliwych kłopotów, występujących przy masowym przetwarzaniu lub sporadycznie przy ręcznym procesowaniu
- definicji tabel - należy definiować kolumny literałów w tabelach jako NAZWISKO VARCHAR2(50 CHAR), a nie NAZWISKO VARCHAR2(50 ) lub o zgrozo NAZWISKO VARCHAR2(50 BYTE). Niektóre narzędzia CASE nie są świadome tego problemu
- definicji zmiennych znakowych w kodzie - przy definicji zmiennych należy w sposób jawny ( tylko spacja i cztery dodatkowe litery CHAR) deklarować semantykę znakową
ALTER SESSION SET NLS_LENGTH_SEMANTICS = BYTE
i wykonajmy poniższy blok
DECLARE
vc_zmienna VARCHAR(3 );BEGIN
vc_zmienna :='ość';
END;
otrzymamy wyjątek::
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 4
bo
SELECT vsize('ość') FROM dual
zwraca 7 (funkcja vsize zwraca wielkość zmiennej w bajtach)..
Okazuje się, że w przypadku ustawień mojej bazy polskie ogonki kodowane są na 3 bajtach, na innych bazach z innymi ustawieniami NLS może to być inna wartość..
Dopiero kiedy poprawimy wartość wielkość zmiennej vc_zmienna na wartość zwracaną przez funkcję vsize, blok zadziała poprawnie..
Powyższy blok zadziała poprawnie, jeśli parametr NLS_LENGTH_SEMANTICS będzie mieć wartość CHAR po wykonaniu instrukcji
ALTER SESSION SET NLS_LENGTH_SEMANTICS = CHAR
Poprawmy blok
DECLARE
vc_zmienna VARCHAR(3 CHAR );BEGIN
vc_zmienna :='ość';
END;
Powyższy bok zawsze zadziała poprawnie na bazach o różnch ustawieniach i tak też należy kodować..
Opisywany problem jest szczególnie dokuczliwy przy przenoszeniu danych pomiędzy bazami o różnych ustawieniach semantyki oraz dystrybucji kodu po różnych firmach.. Często pierwszym ratunkiem jest bezmyślne zwiększanie wielkości pól, aż dana funkcjonalność dobrze zadziała
Brak komentarzy:
Prześlij komentarz