Blog programisty w Oracle PL/SQL

Jest to blog eksperymentatora programisty w PL/SQL dla Oracle. Wszystkie kody tutaj zamieszczone mogą być dowolnie wykorzystywane i zmieniane. A jeśli Ktoś z Gości znajdzie błąd, będę niezwykle wdzięczny...
Zapisz

Szukaj na tym blogu

środa, 12 stycznia 2011

Semantyka bajtowa i znakowa a poprawność kodu

Jest to temat szeroki... Należy zacząć od tego, że problem zależy od

  • 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ą
Ustawmy sobie parametr na poziomie sesji
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