Tipos de campos quando são alterados!

Bugs
#1

Bom dia, Estou me deparando com um bug muito chato e que tem atrasado o meu desenvolvimento!
Esse bug consiste nos tipos de campos que estão no banco de dados, quando o campo é alterado em um formulário de Consulta (grid), ele não altera altomaticamente como nos formulários (form), temos de alterar na mão.
Até ai, tudo bem, sem maiores problemas, mas o bug consiste na hora de alterar esses campos manualmente, que não são alterados corretamente!
Exemplo:

Tenho 2 campos data, Data_Entrada (date) e Data_Saida(Varchar 255). Esse Data_Saida foi criado errado no banco e o erro só foi verificado depois que a consulta já tinha sido construida e todas modelada.
Em seguida o campo Data_Saida foi alterado para (date) e foi todo feliz fui no campo e alterei de Texto para Data, fiz todas as configurações e compilei, mas as datas são exibidas como Texto e não como o campo Data:

Data_Entrada : 13/12/2011
Data_Saida: 2011-12-14

Eu fucei em tudo e não consegui arrumar!
Dai surgiu a ideia de postar aqui esse bug, pois para corrigir isso, tive de deletar a aplicação consulta em questão e criar novamente!

Grato!

#2

Ideal é modelar totalmente o projeto, e depois de revisado começar a programação, lembrando que todo projeto se começa no papel. De qualquer forma, nunca me deparei com esse problema, mas acredito que o sc memoriza e não exclui o campo, apenas esconde e quando o campo retorna ele habilta nas configurações originais.

#3

Concordo plenamente com você Haroldo, porem as vezes passa alguma coisa despercebida, mesmo estando no papel o projeto e sendo revisado por uma equipe!

#4

eu me deparei com um problema parecido essa semana, para nao deletar a consulta eu alterei a para sql select * from tabela, deu certo dessa forma porque os nomes dos campos foram alterados tambem, antes eu comentei dentros dos eventos com // . depois eu joguei a sql com a inner join dentro da consultas e com campos foram alterados para o nome que eram antes e que estavam sendo utilizados pelos eventos
Ficou como cambiarra mais deu certo.

#5

Boa tarde,

Provavelmente este problema está acontecendo porque o SC está fazendo “referência” a antiga Consulta. Para que isto não aconteça, o Sr. deve deletar a antiga aplicação gerada na pasta /app/Projeto/NomeDaAplicação (ex: /usr/local/Zend/apache2/htdocs/scriptcase/app/Testes/controle). Em seguida, rode a aplicação novamente e verifique se nas configurações do campo, se o tipo do SQL e o tipo do Campo está como Data ou Texto.

Note que ao deletar apenas esta pasta, sua Grid continuará funcionando da mesma maneira.

Atenciosamente,
Bernhard Bernsmann

#6

Se essa sua colocação for verdadeira, não poderemos confiar na geração do código pelo sc, pois se ele não mata o conteúdo da pasta para regerá-lo fica complicado hein? desculpa, devo descordar da sugestão ou a interpretei errado.

#7

Haroldo,

Sujeira no código interpretado pode ser causado por diversos motivos. Como sabemos, por vezes o próprio browser pode gerar sujeira, fazendo com que o usuário que está acessando o site tenha de limpar o cache.

Atenciosamente,
Bernhard Bernsmann

#8

Cache de browser é uma coisa, a pasta onde o sc gera o codigo é outra, nessa pasta o browser não irá colocar sujeira, e sempre que o sc gera o código a pasta da app é recriada, então não procede ter que limpa-la no ambiente de desenvolvimento, em produção se a publicação não estiver sendo realizada por completo aí sim.

#9

Haroldo,

A sujeira pode acontecer por exemplo, durante a publicação de aplicações. O mesmo pode acontecer ao gerar o fonte das Consultas que tiveram o SQL modificado.

Note que toda a Consulta, não perderá suas configurações apesar da aplicação gerada ser a antiga.

Atenciosamente,
Bernhard Bernsmann

#10

Bem, eu não ia dar essa sugestão, pois acho perigosa, por isso antes de aplicar, garantam backup geral dos vossos projetos.

1)Editem a tabela do scriptcase: sc_tbapl
2)Alterem o campo NomeTabela: altere o nome da tabela
3)Alterem o campo ComandoSelect: altere o nome da(s) tabela(s) após o FROM

*O campo Tipo_Sql, Tipo_Dado_Consulta, Tipo_Dado_Filtro em sc_tbcmp, contem o tipo de coluna e tipo de campo.

Lookups de campos, etc, deverào ser alterados pelo IDE.

Esse procedimento não vai perder as configurações dos campos, mas alerto para realizarem com a máxima atenção.

#11

Haroldo,
Qual programa posso utilizar para editar os arquivos sqlite?
Pois meu scriptcase está configurado no padrão, com o banco sqlite!

Grato

#12

Não aconselho ninguém a atualizar o SELECT da aplicação desta maneira. O modo que expliquei em meu primeiro post funciona perfeitamente.

Note que ao esquecer de um simples WHERE no UPDATE da tabela, você atualizará todos os registros de uma só vez.

Atenciosamente,
Bernhard Bernsmann

#13

Eu não utilizo sqllite, mas uma pesquisa na web traz vários:

http://sqlitestudio.one.pl/index.rvt?act=download

#14

Bernhard,

Concordo com o perigo de tal procedimento, procedimento este que utilizo a anos e descordo que sua sugestão resolva a questão, pois como afirmei antes, ao gerar o código o sc recria a pasta limpando, removendo todos os arquivos da mesma, basta gerar o código, e o problema persiste, pois ele se dá ao alterar a instrução sql de select da consulta, ao salvar a janela, o sc em consultas não refaz o sincronismo com a tabela quando o sql é alterado, este problema é bem antigo.
Os arquivos gerados na pasta da app são os resultados de uma geração, e não afetam a edição da app em desenvolvimento, muito menos as características dos campos, ou estou entendendo errado a questão principal deste tópico que é: Ao ser mexer no select, ou na estrutura de tabela principal da app, não atualiza as características (propriedades) dos campos envolvidos no select, isso durante a edição da app no modo desenvolvimento.

Reação Web, por favor, nos diga se minha interpretação está errada, se estiver, me desculpem os colegas.

#15

renomeie o nome do campo e atualize o sql na consulta depois renomeie novamente para o nome original e novamente atualize o sql dessa maneira consegui resolver esse tipo de problema sem correr grandes riscos

#16

Deu certo! Valew!!!