Alguns probleminhas com o sc5

Saudação a todos!

Estive acompanhando os testes que o Rodrigo executou no servidor dele e também fizemos alguns testes no meu servidor (2ghz + 1gb ram). O resultado foi o seguinte:

  • Durante 4 meses de utilização do scriptcase (com outros recursos/serviços simultâneos) o pico de utilização do processador foi de 18%;

  • Num único dia, quando fizemos o mesmo teste que o Rodrigo descreveu acima, o consumo subiu pra 37%, sendo que os outros serviços estavam parados (apenas o sc rodando).

Percebi que a engine do sc5 realmente melhorou muito (sem ironia), mas acredito que algum processo está “roubando” os recursos quando trata-se de aplicações com muitos campos…

Sei que é complicado diagnosticar um problema deste tipo pois são muitos fatores que influenciam no resultado, mas seria bem interessante se algum colega pudesse refazer o teste citado pelo Rodrigo, independente do ambiente utilizado, pois assim poderíamos tirar uma grande dúvida e descobrir (ou pelo menos tentar descobrir) a origem do mesmo.

Att.
Robson

Está dando um erro qdo tento compilar uma app do tipo controle:

"
Aplicação não pode ser gerada: Falta definir um campo que seja Chave Primária.
Configure a chave primária em: Aplicação->Formulário->Configuração do SQL.
"

Sabem o que ocorre??!?!?

Abraços!!!

Estranho, dar esse erro numa aplicação de controle.

Senhores,

É inquestionável a melhoria que a V5 trouxe, com suas novas funcionalidades etc etc etc., justamente por estas melhorias há de se entender que esta nova versão consuma mais recursos, mas tenho que concordar fortemente com a indignação do Rodrigo, a lentidão depois que fiz o upgrade para a V5 chega a ser irritante.

Abraços

William Scardua

Isso significa que a cada melhoria mais consumo? Discordo que tenha que ser assim, as melhorias devem acontecer sempre, e ganho de produção também, para tal a performance também deveria melhorar. Ainda não estou produzindo na v5, mas obviamente que além dos investimentos para obter a versão e suporte para mais um ano, terei que trocar de servidor para garantir uma performance mínima exígivel. Mas acredito que o fornecedor da linguagem já deva estar estudando esse picos de uso de cpu, e com certeza vai contornar o problema.

Já estou usando o SC5 em produção, converti todos os sistemas e já fiz UP deles nos clientes, e estão todos satisfeitos, como mudei o tema para o da versão 5, alguns em alguns relatórios pediram apenas para tirar as molduras e bordas, isso fiz editando o esquema, mas no resto esta 100%.

Tentei usar o novo esquema de senhas, gerado pela propria aplicação usando user/group/app, mas não achei onde define os niveis de acesso as aplicações no grupo: tipo: incluir, alterar, consulta, excluir, então acabei ficando com o meu que já faz tudo isso por enquanto.

Para desenvolvimento uso um servidor local UBUNTU 9.10 - INTEL Q6600 - 12 GB RAM - 1 TERA HD e 10 MB de NET, e aparentemente não notei nada relativo a lentidão aqui no desenvolvimento, e para falar a verdade esta bem mais rápido que o sc4 para salvar, carregar, gerar e executar, mas cada caso é um caso.

E hospedo os sistema no UOL HOST ou em alguns clientes localmente com o ubuntu 9.10 em rede local que montei para eles.

Pessoal, quero apenas lembrar que a lentidão a que me referi é apenas em casos de edição de campos em tabelas com grande qtde de campos. Nos meus testes, junto com o Robson, testamos a edição de uma apl de consulta com 72 campos. Para trabalhar com qtdes menores, tipo 10 ou 20 campos o SC5 não demonstra nenhuma lentidão.

Em nenhum momento falei que o SC5 é mais lento que o SC4, muito pelo contrário, está bem melhor. A lentidão a que me referi extende-se à versão 4 também, somente com apls de muitos campos. Em nossos testes o tempo entre salvar um campo e passar para outro, foi o mesmo nas duas versões.

Rodrigo Araújo

Este problema com tabelas com grande quantidade de campos é crônico no SC. Notei isso logo que comprei o SC. Tanto no ambiente de desenvolvimento quanto na produção. Na produção o tempo em que o frm é aberto e “liberado” para o usuário era muito. Efetuei algumas modificações no server de produção que amenizou a lentidão: instalei o SC na produção para as apps rodarem no ambiente do SC. Isto por si só já me deu um ganho de performance considerável e eliminou muitos bugs que só se apresentavam na produção.

Setup: Dell Poweredge 1800 Xeon 3.0 + 3GB RAM + 2MB Full de link + WS 2003 + Ambiente SC instalado.

Como descobrir qual é este ‘elements[…]’ ? , na V4 estava ok
– Na linha 1592, não diz nada que me ajude.
"
Mensagem: ‘document.F1.elements[…].value’ é nulo ou não é um objeto
Linha: 1592
Caractere: 5
Código: 0
URI: http://frm_Bx_Ctas_Receber_Individual/frm_Bx_Ctas_Receber_Individual.php
"

Grato
André

Haroldo, não quis dizer que a lentidão evidente na nova versão do SC é justificável pelas novas funcionalidades que foram implementadas, não foi isso… se não, também não estaria reclamando…, é claro que novas versões devem levar em consideração varias questões importantes, o respeito ao legado do cliente e a performance de desenvolvimento/produção são algumas delas, o mais importante desta discussão é que sinalizamos para que o desenvolvedor da ferramenta ataque este ponto vulnerável, e esperamos que o faça logo …

RESOLVIDO: o problema é que tinha um bloco em “Layout \ blocos \ Blocos não exibidos”, foi só exibí-lo novamente e o erro não aparece mais.
Porque tem esta opção, se quando é usada dá erro? Qual o modo certo de seu uso?

Grato
André

Senhores, boa tarde.

Estou com o mesmo problema de CGI ERRO no IIS. E havia optado em não ter contrato de suporte, somente de upgrade. E agora? tenho que publicar minha aplicação, antes de fechar negócio o cliente havia me perguntado se minha aplicação funcionava com IIS no hospedeiro dele eu disse que sim.

Apenas os cadastros em grid(view), funcionam as consultas que antecedem os cadastros dão erros de CGI.

Como resolver isso num prazo curto.

Espero que alguém já tenha passado por este problema e que tenha a solução para me ajudar.

Um abraço a todos.

William Rodrigues