Referente campo select com lookup manual

Ola Pessoal

Estava com problema em 1 formulario com um campo select lookup manual (S-SIM e N-Não) que na gravação tanto de edicao como de inclusao sempre voltava ao primeiro item (Sim) apesar de ter gravado como Não; porem o banco de dados ficava o certo (S ou N); ou seja quando entrava em modo de edição sempre aparecia como SIM.

Revendo os topicos do forum verifiquei o http://www.scriptcase.com.br/forum/index.php/topic,13019.msg67862.html#msg67862

onde diz :
Constatei que o problema é que se definir o campo, no banco de dados, somente como character(n) não funciona
tem que ser “character varying(n)”. Não era para ser assim, mas, alterei no banco de dados e funcionou.
Quando o campo , no banco, está “character(n)” o SC informa no desenvolvimento da aplicação como “BPCHAR”.
Se não for definido como select, radio ou check o conteudo é salvo normalmente.


quando mudei o campo nvarchar(1) resolveu.

Alguem mais passou por isso; pois gastei muito tempo para conseguir resolver.
Será que devo notificar como bug ?

At.
Moacir de Oliveira

Moacir,

É uma boa pergunta, pois no MySQL funciona normalmente com VARCHAR(1) ou CHAR(1). Talvez a forma como o SC trabalhe com o PGSQL seja um pouco diferente nesse caso. Aí somente o pessoal da Netmake poderá te dar uma resposta mais concreta.

Ola

estou usando o sql server 2012, não me atentei para este detalhe.

at.
Moacir de Oliveira

Na verdade varchar e char tem comportamentos diferentes do MySQL quando se usa o PostgreSQL.
Inclusive o manual alerta que conforme o uso de char você pode obter resultados inesperados.
https://www.postgresql.org/docs/9.6/static/datatype-character.html

Logo, conforme o SGDB você pode ter as questões:

  1. como char tem tamanho fixo tudo que for armazenado nele e tiver um resultado maior que sua capacidade será truncado
  2. Tudo que for menor terá espaço em branco acrescentado para preencher o tamanho da coluna.

Veja: http://sqlhints.com/2011/10/23/difference-between-sql-server-char-and-varchar-data-type/

E etc.