+

Teke susidurti kai viens studentelis sukures buvo DB su butent MSSQL char
laukais, veliau grimzdo to pasekoje i dar didesne beda, ieskodamas
informacijos ja pries tai apdirbdamas su System.String Trim funkcija:) to
pasekoje trindamas ne tik nuo galo tarpus bet ir zodzio viduryje :)

Ir tai nekalbant kad informacija buvo jei gerai pamenu unicodine ir vedama 
is web, kur blogiausiu jam atveju naudoti reikia nchar, o geriausiu 
nvarchar - kuris skirtas unicodiniam tekstui laikyt, toki veikejai neretai 
po to pamirsta RTRIM panaudot ir gaunasi daug bugu, kruva nereikalingo kodo 
su tarpu is desines valymu po to..

Jeigu programuotojas panaudoja CHAR tipa tai visada man norisi paklaust, kad 
pagrystu tai bent viena realia priezastimi kam jam to reikia... man toks 
itarimas kad cia eina nuo kokio FOXPRO ir lievu ziniu is univero... kur 
desto greiciausia destytuvai mokinesi dar tais laikais kai buvo tik char ir 
visokios space delimited databases...


"Laimis" <wiela@centras.lt> wrote in message 
news:h20oj6$cf6$1@trimpas.omnitel.net...
> bala nemate rašė:
>>
>> rezultate gaunu, kad @DBName yra 'master                             ', o 
>> ne 'master'
>>
>> o gal iš principo ne tuo keliu einu...
>
> Tikrai ne tuo... ;-)
> Tai vadinama (ansi) blank/space padding (standartas),  ir norint išvengti 
> aibės potencialių siurprizų, būtų labai naudinga atsiminti, kad fiksuoto 
> ilgio tekstiniai laukai (char ir kt.), bendru atveju (jei neįjungta kokia 
> nors legacy, suderinamumo opcija)
> yra būtent tokie -- fiksuoto ilgio ir „space padded“.
> Kita vertus, tai negalioja kintamo ilgio laukams (varchar ir kt.).
> O siurprizai gali būti labai netikėti ir bjaurūs:
>
> INSERT INTO ... 'foo'
>
> ir
>
> SELECT .. WHERE bar = 'foo'
>
> <nieko>, nes
>
>
> 'foo' <> 'foo      '