Ops, desconsidere o link de exemplo final, http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set é o link mais apropriado, que contém um script que muda as colunas string definidas como BYTE limited para CHAR limited....
[]s Chiappa ---Em oracle_br@yahoogrupos.com.br, <jlchia...@yahoo.com.br> escreveu: Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior vc já tinha dito que teu banco 11g E tinha dito que é Express Edition (não diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o tamanho" é ESSa a dedução), e está Completamente Documentado que o Oracle XE ** não ** é oficialmente compatível com qualquer characterset - veja em http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a info : "Table 4 Supported Universal Character Sets Name Description AL16UTF16 Unicode 4.0 UTF-16 Universal character set AL32UTF8 Unicode 4.0 UTF-8 Universal character set UTF8 Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant ---------------------------------------------------------------------------- " Então pra mim ao mandar um comando "Alter database character" para um characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário de dados, sim sim ?? Não é à toa que coisas que dependem de tabelas interas/do dicionário (como export e import) tão quebradas.... OKDOC ? Sabe-se lá de onde vc tirou a informação, mas de repente foi de páginas como http://www.devmedia.com.br/alterando-padrao-de-caracter-no-oracle-xe/9591 , que mostram a mudança no XE ** 10g **, onde elea era possível e autorizada, no XE 11g não mais.... Até ** pode ser ** que recriando o dicionário de dados com os scripts apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar isso por sua Conta e Risco... ===>> Lamento dizer também que vc fez isso à TOA ao saber que WE8ISO8859P1 era o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um subset completo do AL32UTF8 padrão do XE , ** dificilmente ** daria qquer problema se estivesse com NLS_LANG setado corretamente.... Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com BYTES como limitador de strings, e no banco XE com characterset multibyte cada caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela sendo criada como : CREATE TABLE nomedatabela (C1 number, C2 varchar2(30), C3 ...... No exemplo acima, no banco-origem com characterset single-byte WE8ISO8859P1 a tabela seria criada com a coluna C2 podendo receber até 30 bytes, que correspondem a 30 caracteres (pois em single-byte cada caracter ocupa um bytes), *** MAS *** com as configs padrão no XE a mesma tabela seria criada com a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30 CARACTERES (em UTF cada caracter pode ocupar MAIS de um byte).... Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de extrair os CREATEs das tabelas para confirmar isso), mas meu feeling é que é esse o seu problema.... A solução portanto seria (num database XE ** recriado **, não vale o trabalho de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR que o NLS_LANG está corretamente setado, extrair os DDLs dos creates para confirmar a issue (que estará confirada TANTO se vc não ver nada na definição do tipo de limite da string como eu mostrei QUANTO se vc ver algo tipo C2 varchar2(30 BYTE)), E uma vez conbfirmada vc TERÁ que alterar os DDLs para que passem a informar o limite em CARACTERES e não em BYTES, veja http://stackoverflow.com/questions/30707293/import-dmp-file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database para um exemplo.... []s Chiappa
