[Resolvido] Problemas (SQL Server 2005)

[Caduzera 0]

Pessoal, tudo certo?

 

Seguinte tenho um problema com o SQL Server 2005 e não faço a mínima de como resolver.

 

Tenho a versão do SQL Server 2005 Express instalada na minha máquina, e executo nela um comando assim:

 

UPDATE TABELA SET CAMPO = ' ' WHERE CODIGO = 1

 

Eu quero inserir em um campo três espaços em branco. Esse campo é um VARCHAR(3). Isso funciona OK na minha versão Express.

 

Quando executo o mesmo procedimento em um dos nossos servidores com a versão Enterprise do SQL Server, ele não se comporta da mesma forma.

 

Ao invés de inserir os três espaços em branco, ele inseri apenas 1.

 

O que pode ser??? Alguma configuração???

 

Valeu pessoa !!

[advaldomesquita 93]

Tem ctza que no Express ele guarda 3 espaços?

A locação de dados, com relacao ao espaço (ASCII 32) não repete quando se tem dois espaços.

 

Exemplo:

 

declare @teste table (campo1 varchar(3), campo2 char(3), campo3 nvarchar(3), campo4 nchar(3))

insert into @teste values ('   ','   ','   ','    ')

select len(campo1), len(campo2), len(campo3), campo4,len(campo4) from @teste

 

Voce pode até tentar usar o ASCII para pegar o caracter espaço, mas NÃO vai funcionar. O resultado vai ser o caracter espaço sendo alocado somente uma vez.

 

declare @teste table (campo1 varchar(3), campo2 char(3), campo3 nvarchar(3), campo4 nchar(3))

insert into @teste values ((char(32)+char(32)+char(32)),'   ','   ','    ')

select len(campo1), len(campo2), len(campo3), campo4,len(campo4) from @teste

 

Se tiver duvidas se o CHAR(32) é o espaço:

select ASCII(' ')

 

Pergunto: Para que guardar 3 espaços? O_o

 

Abçs

 

 

 

 

[Caduzera 0]

Obrigado pela resposta!!

 

Tenho certeza sim. Porque após executar o comando rodo o SELECT abaixo para verificar !!

 

SELECT '&' + CAMPO + '&' FROM TABELA WHERE CODIGO = 1

 

Ele mostra 3 espaços em branco entre os &, além do fato da aplicação funcionar corretamente apontando para esta base de dados.

 

Veja que se você rodar o seguinte SELECT após o teste que você passou, ele irá mostrar os espaços em branco. (PELO MENOS ISSO OCORRE NA MINHA VERSÃO)

 

 

select '&' + campo1 + '&', '&' + campo2 + '&', '&' + campo3 + '&', '&' + campo4 + '&' from @teste

 

 

Eu fiz a migração do sistema de Firebird para SQL Server, como a aplicação estava desta forma preciso pelo menos por enquanto manter este padrão.

 

Me ajudem !!!!

[advaldomesquita 93]

Quando se concatena qualquer valor com espaço ele conta como três.

Ou seja,

quando você concatenou o '&' com o campo1, ele assumiu que o campo1 tem 3 caracteres, pois esta gravado assim no banco!

 

Vizualizando a tabela (select * from) ele vai mostrar somente um caracter, mas a partir do momento que concatenar, ele vai assumir os 3 caracteres que estao gravados!

 

Isso tudo se o campo for VARCHAR

 

Olha isso:

 

declare @teste table (campo1 varchar(30), campo2 char(30), campo3 nvarchar(30), campo4 nchar(30)) 

insert into @teste values ('   1','   1','   1','   1') 

select len(campo1), len(campo2), len(campo3), len(campo4) from @teste

 

O resultado do campo4 vai ser 1 e não 4 como deve ser.

 

Entendeu? :P

[Caduzera 0]

Entendi ... !!

 

Mas mesmo assim, se pegar o resultado do SELECT:

 

SELECT CAMPO1, CAMPO2 FROM TABELA WHERE CODIGO = 1 (OS DOIS CAMPOS SENDO GRAVADOS NO BANCO COM TRES ESPAÇOS EM BRANCO)

 

Se mandar salvar o resultado da consulta (que faço via Management Studio) em um arquivo CSC ele me salva os campos com tres espaços em branco !!!

 

Então por mais que estivesse vendo errado o resultado concatenando o campo, quando salvo o mesmo ele mostra o que realmente esta gravado no banco.

 

Isso mostra que lá estão os três caracteres salvos !!

 

 

PORQUE FUNCIONA NO EXPRESS E NÃO FUNCIONA NO ENTERPRISE ?? PODE SER O WINDOWS??

 

Valeu pela ajuda !!

[Caduzera 0]

Entendi ... !!

 

Mas mesmo assim, se pegar o resultado do SELECT:

 

SELECT CAMPO1, CAMPO2 FROM TABELA WHERE CODIGO = 1 (OS DOIS CAMPOS SENDO GRAVADOS NO BANCO COM TRES ESPAÇOS EM BRANCO)

 

Se mandar salvar o resultado da consulta (que faço via Management Studio) em um arquivo CSC ele me salva os campos com tres espaços em branco !!!

 

Então por mais que estivesse vendo errado o resultado concatenando o campo, quando salvo o mesmo ele mostra o que realmente esta gravado no banco.

 

Isso mostra que lá estão os três caracteres salvos !!

 

 

PORQUE FUNCIONA NO EXPRESS E NÃO FUNCIONA NO ENTERPRISE ?? PODE SER O WINDOWS??

 

Valeu pela ajuda !!

[advaldomesquita 93]

Agora quem nao entendeu fui eu.

 

Você precisa mostrar o resultado com os três espaços em branco ou gravar o resultado com os três espaços em branco?

 

Eu quero inserir em um campo três espaços em branco. Esse campo é um VARCHAR(3). Isso funciona OK na minha versão Express.

 

Quando executo o mesmo procedimento em um dos nossos servidores com a versão Enterprise do SQL Server, ele não se comporta da mesma forma.

 

Ao invés de inserir os três espaços em branco, ele inseri apenas 1.

 

O que pode ser??? Alguma configuração???

 

[Caduzera 0]

Desculpa se estou te confundindo !!

 

Eu preciso salvar as informações com três espaços em branco no banco !! Porque minha aplicação faz uma comparação assim:

 

if Campo = ' ' then

--

--

 

Quando eu falei sobre o arquivo csv era só um modo de provar que na versão Express a informação é salva como eu quero no banco (com três espaços) mas na versão Enterprise não !!

 

Quando executo minha aplicação na versão Express ele entra na condição de IF apresentada !!

 

Quando executo minha aplicação na versão Enterprise ele não entra na condição de IF porque no banco esta apenas um espaço em branco ' ' !!

 

Valeu !!!

[advaldomesquita 93]

O Collation das duas bases estão iguai? A versão do Windows são as mesmas? Os services packs do servidor estão instalados?

Eu acho que é o collation. Podem estar diferentes, o resto é somente para conhecer o ambiente.

Eu testei em quatro ambientes:

Ambiente 1:

DB Collatin SQL_Latin1_General_CP1_CI_AI

SQLServer 2005 Express SP3

 

Ambiente 2:

DB Collatin SQL_Latin1_General_CP1_CI_AI

SQLServer 2005 Enterprise SP3

 

Ambiente 3:

DB Collatin SQL_Latin1_General_CI_AI

SQLServer 2008 Express

 

Ambiente 4:

DB Collatin SQL_Latin1_General_CP1_CI_AI

SQLServer 2008 R2 Enterprise

 

E o este "erro" ocorreu somente no ambiente 3!!! Por isso acho que é o Collation.

[Caduzera 0]

Obrigado pela ajuda !!

 

Na máquina onde esta instalado a versão Express: Windows Vista (SP2) e o Collatin é: Latin1_General_CI_AS

 

Microsoft SQL Server Management Studio 9.00.1399.00

Microsoft Analysis Services Client Tools 2005.090.1399.00

Microsoft Data Access Components (MDAC) 6.0.6002.18005 (lh_sp2rtm.090410-1830)

Microsoft MSXML 3.0 4.0 5.0 6.0

Microsoft Internet Explorer 9.0.8112.16421

Microsoft .NET Framework 2.0.50727.4206

Operating System 6.0.6002

 

 

Na maquina esta instalado a versão é Enterprise: Windows Server 2003 (SP2) e o Collatin é: Latin1_General_CI_AS

 

Microsoft SQL Server Management Studio Express 9.00.3042.00

Microsoft Data Access Components (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710)

Microsoft MSXML 2.6 3.0 6.0

Microsoft Internet Explorer 8.0.6001.18702

Microsoft .NET Framework 2.0.50727.3615

Operating System 5.2.3790

[advaldomesquita 93]

Teste rápido: altere campo de varchar para char(3) e insira os dados e faça o teste do If...

[Caduzera 0]

Cara, não tenho como fazer este teste porque é o banco de produção. Não tenho como modificar o tipo do campo para testar !!

 

E na minha base local a bagaça funciona !!

 

Tem mais alguma idéia ???

 

Abs.

[advaldomesquita 93]

Na sua base de producao, pode ser ateh temporaria, ou fisica de teste.

eu tentaria criar um campo do tipo VARCHAR(3) e um CHAR(3).

Tenho certeza que o char(3) vai resolver seu problema, pois se você nao preencher todo ele, ele põe espaço no resto do campo.

 

Seria minha última idéia, se mais alguém tiver uma, será com certeza bem vinda :joia:

 

 

[Caduzera 0]

Mais alguem se arisca a me ajudar neste problema loco??

 

Depois vou tentar mudar o tipo do campo e testar !!

 

Mesmo assim, obrigado pela ajuda !!

[Caduzera 0]

Pessoal, segue a resposta ao meu problema !!

 

***********

 

Exec sp_help <NomeDaTabela>

 

Provavelmente, na versão Express, você terá a opção TrimTrailingBlanks, correpondente à coluna da sua tabela que está sendo atualizada, como "no" e na versão Enterprise estará como "yes".

 

Quando está propriedade está definida como 'yes', ao gravar os dados na tabela o SQL Server retira os espaços em branco após a string. Por exemplo: 'valor 1 ', será gravado como 'valor 1'. Porém, quando a propriedade estiver como 'no' os dados serão gravados com os espaços no fim.

 

Se este realmente for o seu problema, você pode alterar esta propriedade efetuando um alter na coluna que você está tentando atualizar, porém, deve especificar antes

 

SET ANSI_PADDING ON

 

conforme o exemplo do Marcelo.

 

Quando você criar ou alterar uma coluna de uma tabela com a opção ANSI_PADDING ON, essas colunas armazenaram os espaços em branco após o texto. Agora, se você utilizar a opção ANSI_PADDING OFF, o SQL Server descartará os espaços após o texto.

 

Ex para alterar o propriedade para que passe a armazenar os espaços em branco após o texto:

 

SET ANSI_PADDING ON

Go

ALTER TABLE <Tabela> ALTER COLUMN <Coluna> <Tipo> [Constraints]

[advaldomesquita 93]

Que bom que resolveu cara! :joia:

 

E com ctza fica a dica para quem precisar :devil: