OK Rodrigo, isso mesmo.
Grato
André
Isto também era assim no SC4, porém, não gera erro na execução da aplicação e no SC4 pelo menos depis que compilava ficava com o título da aplicação copiada.
Cleyton Euler,
O problema é dentro do SC5, as aplicações funcionam normal.
Já passei pro suporte e abri um ticket pra acompanhar, mas até agora ninguém respondeu.
Rodrigo Araújo
Então, no SC4 isso acontecia também mas após a compilação da aplicação ele pegava o novo nome da aplicação.
Boa Noite Galera
To com um problema no SC_lookup com campo do tipo “Data e Hora”
Em uma aplicação de controle, no momento em que o usuário informa o login, deveria retorna a data e hora do seu ultimo acesso. Mas no SC5 tentei de varias formas e nada. Alguém teve o mesmo problema?
Os campos sãodo tipo datetime (no BD MySql) e data e hora no SC AAAA-MM-DD HH:II:SS (formato interno)
sc_lookup(dat, "
SELECT
us_login,
us_nivel,
us_ult_ac
FROM
usuarios
WHERE
(us_login = ‘{usuario}’)");
{nivel} = {dat[0][1]};
{ult_acesso} = {dat[0][2]};
No SC4 esta funcionando perfeitamente.
Att
Helder
Nas consultas quando se usa o Group Label, no PDF gerado o Label sai no lugar errado.
Boa Tarde Robson,
Abri um tópico explicando a solução para este problema.
http://www.netmake.com.br/forum/index.php?topic=1418.0
Rodrigo Lins.
Boa Tarde Robson,
Este problema do SUM já foi identificado e corrigo, em breve deverá a release corrigindo este problema e alguns outros.
Rodrigo Lins.
Boa Tarde Rodrigo,
Com relação ao problema da acentuação da tabela já está sendo corrigido também, verifiquei que só acontece o problema na tela de “Criação expressa”, nas demais estão funcionando.
O problema da paginação que quando estava total não mostrava o resumo de registros, agora está funcionando corretamente.
Outro detalhe, é que cada template tem variáveis diferentes, e estas variáveis estão definidas no próprio HTML que foi criado. Se, por exemplo, você criar novos templates HTML irá mostrar o nome da variável que você definir. Então, estas irão variar de acordo com o template selecionado.
Serão liberados na próxima release.
Nos outro problemas não consegui simular… Caso esteja acontecendo todos eles mesmo assim, gostaria que entrasse em contato com o suporte.
Rodrigo Lins.
Boa Tarde Helder,
De fato funcionava, eu verifiquei. Mas, se fiz diferente um pouco na V5 ele irá funcionar também.
Pelo que vi você já passou para o email de bugs este problema, ele deve estar sendo analisado e corrigido caso necessário.
O que ocorre é o seguinte, no campo “Data e Hora” são exibidos 2 inputs, e de fato são 2. O input de hora é chamado assim: “nome_campo_hora” , com este sufixo _hora. Fiz um teste e funcionou da seguinte maneira.
Ex.
sc_lookup(dat, “SELECT ultimo_acesso
FROM tb_login”);
{data_ultimo} = {dat[0][0]};
{data_ultimo_hora} = {dat[0][0]};
Enquanto não é visto este caso, ou corrigido, você pode utilizar desta forma.
Espero ter ajudado.
Rodrigo Lins.
Boa Tarde,
Fiz um teste não aconteceu este problema na geração do PDF, na release que irá sair em breve, já deverá corrigir este problema.
Rodrigo Lins.
Cabe esse mesmo problema relatado a minha mensagem de erro também ? ERRO
Erro ao acessar o banco de dados
[Oracle][ODBC]Option value changed.
select count(*) from SCI.SCI_RSMD_ARRECADA_DIA where DT_PAGTO between ‘2009-12-01’ and ‘2009-12-01’
Eu fiz uma pesquisa para uma consulta, entre duas datas. Na tela da pesquisa está dd-mm-yyyy porém o SQL, conforme mensagem de erro acima.
Já tentei ajustar o formato e nada… e o parametro tem que ser passado pelo cliente na tela de pesquisa.
Bom Dia,
Este select do erro, foi feito através da macro sc_lookup? E o tipo de dado é Data e Hora, se sim, seria o mesmo caso, para fazer referencia ao campo data teria que colocar o sufixo _2.
Rodrigo Lins.
Rodrigo, quando vai sai a release?
Grato
André
Em minha instalação o SC5 esta extremamente lento, o SO é o Windows XP Service Pack 3. Alguém esta passando por isso?
George Carvalho
Em aplicações FORM quando preciso sincronizar a tabela, se algum BLOCO contiver palavras acentuadas elas ficam danificadas.
Será que o problema é na minha instalação do SC5, instalei a partir do instalador disponibilizado na pagina do SC.
George Carvalho
Saiu hoje: 24/12 - Segue changelog:
Versão 5.0.001
Gerador:
-Implementação de um log das atualizações efetuadas atraves do scriptcase update.
Implementação da opção de selecionar arquivos de cep na publicação tipica.
Implementação do botâo de maximizar e restaurar na aplicação de container.
Implementação na interface do scriptcase da opção para escolher se a impressâo do pdf deve exibir o background do tema.
Implementação de ligação modal para botôes de ligação da aplicação.
Implementação de mensagem de controle de sessâo nas aplicações geradas.
Melhoria no formato de exibição de erros dos formulários gerados.;
-Correção do fonte da mensagem de inexistencia de registros da consulta.
Corrigido erro de formatação do rodapé do pdf.
Correção no detalhe da consulta, a opção de unidade de largura.
Corrigido problema de regras de ordenação na consulta.
Corrigido, na aplicação de container, problema nas regras de segurança.
Corrigido cabeçalho e rodapé do container.
Corrigido problema das margens na consulta.
Corrigido problema de exibição de quantidade de linhas, na consulta com paginação total.
Corrigido problema ao renomear e excluir temas de visualização.
Corrigido problema de exibição das bibliotecas.
Ajustes no funcionamento do menu de edição de aplicações, no chrome e firefox.
Corrigido problema nas aplicações de filtro com o tecla enter.
Corrigido problema nas cores do tema, após impressão economica.
Corrigido problema de mascara de campo no chrome.
Corrigido problema de inclusão de novos registros na grid editavel.
Corrigida a opção de retornar após inclusão, no formulário grid editavel.
Corrigido problema com o cep.
Corrigido problema na exibição do menu treeview no ie8.
Ajuste no alinhamento do total do resumo.
Corrigido o CSS na conversão do resumo.
Corrigido problema de erro na macro sc_ajax_message.
Corrigida a exibição de tabelas com acentuação, na criação de aplicações na forma “expressa”.
Corrigida a configuração dos gráficos de coluna.
Corrigido problema de case sensitive em lookups.
Correção do css na criação de botões exclusivos da aplicação.
Corrigido problema de exibição do diagrama do projeto em maquina linux. Foi criado um tutorial explicando a instalação, na base de conhecimento.
Corrigido problema de funcionamento do container no firefox2 no windows.
Corrigido problema de select com alias do sqlite.;
** Dica para as aplicações importadas da versão anterior onde um formulário tinha um botão que fazia chamada a uma consulta e tinha que iniciar a mesma pelo filtro na consulta na hora de fazer a ligação tem que se marcar como iniciar a consulta (filtro ou consulta) se deixar em branco ele abre a consulta diretamente, parece um bug mas não é que foi mudado o esquema de fazer a ligação, mas esta funcionando 100% aprovado.
Estou mudando o esquema das minhas (layout visual) aplicações para os esquemas scriptcase v5, parece que fica mais bonito e leve.
Uma característica que pra mim está deixando o SC5 impossível de operar é a lentidão quando temos forms ou consultas com mais de 50 campos por tabela. Passou de 20 ele começa a se arrastar, e a impressão que tenho é que a medida que vc vai descendo na lista de campos, pra configurar alguns detalhes, a lentidão vai aumentando ainda mais.
Uso o SC5 num servidor cloud server linux na locaweb, que só tem o básico para operação e hospedagem dos projetos. Desconfiei do meu link de internet (velox 600), mas em conjunto com o amigo Robson aqui do forum, que abriu meu SC5 e tentou executar a mesma tarefa, a demora foi a mesma. Detalhe, o link dele é de apenas 10Mbits, infinitamente superior ao meu. Cronometramos, e na mesma tarefa, entre salvar as alterações de um campo e abrir o próximo, são exatamente 1 minuto e 15 segundos.
A medida que o projeto vai crescendo vai piorando ainda mais. Basta dizer que digitei este post inteiro e continuo aguardando o SC5 pular de um campo pra outro.
Sinceramente, não comprei o SC5 pra fazer agenda telefônica.
Completamente descontente e arrependido da aquisição,
Rodrigo Araújo
Boa Tarde,
Qual o banco de dados que está sendo utilizado pelo ScriptCase? O ScriptCase está utilizando uma base de dados (das aplicações criadas) no mesmo servidor ou está em locais diferentes?
Estes detalhes fazem uma diferença com relação à velocidade… Quando diz-se problemas de “lentidão” é sempre complicado, porque existem inúmeros ambientes diferentes e configurações… As vezes vemos casos de, por exemplo, uma simples operação que em uma máquina é rapida e em outra máquina (similar) é lento, quando faz-se uma verificação detalhada identifica que é um problema de configuração (de versão de php, por exemplo)… E assim, como outras coisas.
É uma coisa muito ampla e pode-se dizer complexa falar de ambientes, de fato tem que ser analisado para atentar se isto acontece somente neste ambiente ou em todos… São muitas variáveis, de fato… Se puder dar mais detalhes das perguntas que fiz no ínicio e outras será interessante para simular o problema e ver uma solução para tal.
Abraços.
Rodrigo Lins.
Olá Rodrigo Lins, boa tarde.
Tenho o SC5 num cloud server mini I da locaweb, com ubuntu server 8, cpu 600mhz, 300mb de ram e link de 2Mbps. Só há 1 instância do Apache/2.2.8 (Ubuntu), PHP/5.2.11e mysql 5.0.51a-3ubuntu5.4.
Conforme vc sugeriu, decidi então testar meu ambiente de produção.
O teste que realizei foi sempre o mesmo, que é o que mais me está incomodando: Com uma apl de consulta, com 72 campos, alterando um dos últimos campos da lista, acrescentando mais 1 item num lookup manual. Ao efetuar a alteração, clicava no próximo campos da lista. Cronometrei o tempo entre dar o OK para salvar o campo atual até a total abertura da tela seguinte.
Usando a instalação padrão do SC5, com banco sqlite:
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:25 segs;
Ao passar de um campo para outro adicionando +1 item ao lookup manual: tempo ~01:50segs.
Usando a ferramenta de acompanhamento de processamento da locaweb, antes de gravar, a cpu marcava entre 2 e 3% de uso. Sempre que mandava gravar pra merdir o tempo, o processamento estourava os 100%. Por várias vezes tive que restartar o serviço do apache, pq meu servidor simplesmente congelava.
Pra mim ficou claro que o problema era do sqlite, durante a gravação.
Decidi então fazer um backup e remover completamente o SC5 do servidor, providenciando uma nova instalação usando o meu banco mysql no lugar do sqlite padrão do SC.
Depois da instalação pronta e atualizada, subi meu projeto e fiz o mesmo teste.
Resultado:
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:04 segs;
Ao passar de um campo para outro adicionando +1 item ao lookup manual: tempo ~01:05segs.
O desempenho do SC5 melhorou com a troca do banco, porém, é fato que ao trabalhar com tabelas grandes, o desempenho parece cair exponencialmente. Infelizmente sou obrigado a trabalhar com algumas tabelas com um grande numero de campos, pois meu sistema se assemelha muito a um tipo de censo.
Estou agora fazendo upgrade no meu cloud server, para cpu de 800Mhz, memória de 600MB, disco de 30GB e link de 4Mbps. Farei mais testes ao terminar e posto aqui os resultados.
Editando…
Acabei de realizar o upgrade do plano de hospedagem para a configuração que citei acima.
Resultado: (exatamente o mesmo teste, com a mesma apl e campo)
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:04 segs;
Ao passar de um campo para outro adicionando +1 item ao lookup manual: tempo ~00:48segs.
Agora um outro teste, usando essa última configuração, pra mostrar o que realmente quero dizer neste post:
Alterando um campo exatamente igual, tipo checkbox, adicionando 1 item no lookup manual. A diferença é que este campo está no meio da lista de campos do SC.
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:03 segs;
Ao passar de um campo para outro adicionando +1 item ao lookup manual: tempo ~00:45 segs.
Alterando um campo tipo texto, mudando o conteúdo do label.
Este campo está no topo da lista de campos do SC (2ª posição).
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:03 segs;
Ao passar de um campo para outro mudando o conteúdo do label: tempo ~00:40 segs.
Agora, em outra apl, consulta com apenas 2 campos…
Ao passar de um campo para outro sem realizar nenhuma alteração: tempo ~00:03 segs;
Ao passar de um campo para outro adicionando +1 item ao lookup manual: tempo ~00:07 segs.
Tenho a impressão que o SC leva mais tempo pra concluir uma mesma operação a medida que o número de campos aumenta. Ficou muito claro que a diferença de ambiente, com o SC usando mysql e numa plataforma de hardware com mais recursos, o desempenho melhorou, porém, o tempo de operação dentro do sc diminui proporcionalmente. O fato é que o tempo de operação dele aumenta conforme o número de campo a se trabalhar também aumenta.
Minha conclusão:
-
Sou obrigado a refazer todo meu sistema, quebrando tabelas em outras bem menores, porém o ganho de tempo na operação do SC será em vão, visto que perderei um outro longo tempo criando e configurando novas apls, sem contar com a inviabilidade por parte do usuário navegar entre tantas telas pra manipular um mesmo grupo de informações.
-
Melhorar drasticamente a infra-estrutura de hospedagem do SC5, na tentativa de que ele responda melhor com minhas tabelas.
Outro detalhe a observar é que as aplicações geradas funcionam normalmente, independente do número de campos na tela, 2 ou 72.
Só não acho justo, é mexer na estrutura de sistema de mais de 7 anos em produção, que funciona perfeito em ambiente desktop com banco sql server (mais lento que mysql), pra poder fazê-lo para web, usando o SC.
Obrigado.
Rodrigo Araújo