none
Encontrar erro na base de dados do cliente RRS feed

  • Pergunta

  • Olá colegas,

    eu já usei outras IDE's onde cada tela era um arquivo separado (exemplo, Delphi e Oracle). Eu podia duplicar a tela colocando outro nome e com as alterações necessárias para localizar o erro. Nesse caso eu acompanhava passo a passo os procedimentos da tela/formulário até achar o erro.

    Já o Visual Studio gera um instalador apenas. Como vcs fazem para encontrar um erro na base do cliente com o Visual Studio?

    Obrigado.


    quinta-feira, 2 de julho de 2015 12:59

Respostas

  • "Ah desculpa, não é um instalador. O que tava querendo dizer é que após instalar o sistema no cliente só vai existir um arquivo do tipo Aplicativo no diretório de instalação (além das DLL's). Quando você comentou que cada Tela/Formulário gera um arquivo acho que quis dizer na programação, pois no cliente só fica o Aplicativo pra rodar o sistema."

    Até onde eu me lembre, no Delphi nao era diferente. Um projeto possuia diversos forms mas o resultado era um unico executavel.

    Ainda nao consegui entender o seu metodo de debugagem.

    O que eu faço normalmente para rastrear problemas:

    1- Metodos pequenos - nao mais de 20 linhas

    2-Isolar pontos criticos com try..catch

    3-Usar un sistema de log. Eu uso o componente NLog nos meus sistemas. Esse componente  utiliza o app.config ou  o web.config (em aplicaçoes WEB) paara controlar o que e como será feito o "trace" do sistema. É calaro que voce tem que incluir em cada metodo o codigo para que o NLog saiba o que sera traçado. Veja um exemplo aqui: https://github.com/NLog/NLog/wiki/Tutorial

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    • Sugerido como Resposta Mr. Morello sexta-feira, 3 de julho de 2015 17:18
    • Marcado como Resposta Matheus L. M. C. Campos sexta-feira, 3 de julho de 2015 17:58
    • Não Marcado como Resposta Eugenio Junior terça-feira, 7 de julho de 2015 12:16
    • Marcado como Resposta Cristopher C I_ terça-feira, 7 de julho de 2015 18:06
    sexta-feira, 3 de julho de 2015 15:06
    Moderador

Todas as Respostas

  • Olá Eugenio, tudo bem?

    Eu acredito que esta "Discussão Geral" que você criou na verdade devia ser uma thread.

    Atenciosamente

    Marcos Robertto

    quinta-feira, 2 de julho de 2015 16:36
  • Opa blz.. já alterei.
    quinta-feira, 2 de julho de 2015 16:53
  • Ninguém passou por essa situação ainda?
    sexta-feira, 3 de julho de 2015 13:45
  • Poderia nos explicar melhor. Cada Tela é um arquivo separado no visual studio tambem.

    Que tipo de erro vc esta tentando procurar?

    Com o SQL Server normalmente eu uso o profiler (ferramenta que acompanha o SQL). Desta forma eu consigo ver o que a aplicaçao envia ou recebe do banco.

    Nao entendi tambem o que vc quis dizer com "Já o Visual Studio gera um instalador apenas. ".

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    sexta-feira, 3 de julho de 2015 13:52
    Moderador
  • Ah desculpa, não é um instalador. O que tava querendo dizer é que após instalar o sistema no cliente só vai existir um arquivo do tipo Aplicativo no diretório de instalação (além das DLL's). Quando você comentou que cada Tela/Formulário gera um arquivo acho que quis dizer na programação, pois no cliente só fica o Aplicativo pra rodar o sistema.

    Imagine a seguinte situação:

    Numa outra tela o usuário parametrizou 5 dígitos num campo sendo que deveriam ser 7 dígitos. Daí ele vai finalizar uma operação, tipo lançamento de nota fiscal, e no meio do código fonte tem o seguinte tratamento: campo_banco.substring(6, 1).

    Nesse caso vai estourar erro porque tá tentando pegar o 6º dígito sendo que ele nem existe, e não vou saber onde tá o problema porque o lançamento da nota é um processo grande e chama inúmeros métodos separados.

    Ficou mais clara a minha dúvida?

    sexta-feira, 3 de julho de 2015 14:23
  • "Ah desculpa, não é um instalador. O que tava querendo dizer é que após instalar o sistema no cliente só vai existir um arquivo do tipo Aplicativo no diretório de instalação (além das DLL's). Quando você comentou que cada Tela/Formulário gera um arquivo acho que quis dizer na programação, pois no cliente só fica o Aplicativo pra rodar o sistema."

    Até onde eu me lembre, no Delphi nao era diferente. Um projeto possuia diversos forms mas o resultado era um unico executavel.

    Ainda nao consegui entender o seu metodo de debugagem.

    O que eu faço normalmente para rastrear problemas:

    1- Metodos pequenos - nao mais de 20 linhas

    2-Isolar pontos criticos com try..catch

    3-Usar un sistema de log. Eu uso o componente NLog nos meus sistemas. Esse componente  utiliza o app.config ou  o web.config (em aplicaçoes WEB) paara controlar o que e como será feito o "trace" do sistema. É calaro que voce tem que incluir em cada metodo o codigo para que o NLog saiba o que sera traçado. Veja um exemplo aqui: https://github.com/NLog/NLog/wiki/Tutorial

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    • Sugerido como Resposta Mr. Morello sexta-feira, 3 de julho de 2015 17:18
    • Marcado como Resposta Matheus L. M. C. Campos sexta-feira, 3 de julho de 2015 17:58
    • Não Marcado como Resposta Eugenio Junior terça-feira, 7 de julho de 2015 12:16
    • Marcado como Resposta Cristopher C I_ terça-feira, 7 de julho de 2015 18:06
    sexta-feira, 3 de julho de 2015 15:06
    Moderador
  • O Oracle gera arquivo .fmx e o Delphi, apesar de gerar um executável final, gera os arquivos .bpl para cada tela. Eu já vi empresas que usam essas ferramentas debugarem o fonte no cliente com mensagens, inclusive já fiz isso também quando usei Oracle.

    Em ambos os casos são duplicadas as telas e na nova o programador coloca as mensagens que ele quer verificar.

    Já no Visual Studio é gerado apenas um aplicativo final quando vai instalar no cliente. São geradas várias telas, mas só para o programador.

    Esse componente NLog precisa ser incluso em cada método? Ele conseguiria mostrar mais informações sobre o erro no caso de uma substring perdido no meio do código sem try/catch?

    sexta-feira, 3 de julho de 2015 18:08
  • Esse componente NLog precisa ser incluso em cada método?

    somente nos metodos que vc deseja rastrear.

    Ele conseguiria mostrar mais informações sobre o erro no caso de uma substring perdido no meio do código sem try/catch?

    Ele consegue mostar aquilo que vc programar pâra mostar... Voce pode guardar o estado de cada uma das variaveis do metodo, se quiser.

    O Oracle gera arquivo .fmx e o Delphi, apesar de gerar um executável final, gera os arquivos .bpl para cada tela. Eu já vi empresas que usam essas ferramentas debugarem o fonte no cliente com mensagens, inclusive já fiz isso também quando usei Oracle.

    O Visual Studio gera um PDB para casa classe. Este arquivo contem informaçoes para debugagem. O Igor, no artigo abaixo, mostra como utiliza-los:

    http://blog.lambda3.com.br/2013/09/para-que-servem-os-arquivos-pdb/

    Em ambos os casos são duplicadas as telas e na nova o programador coloca as mensagens que ele quer verificar.

    O msesmo pode ser feito no .NET... nao estou entendendo a dificuldade. Voce pode copiar e colar um formulario e depois modifica-lo, adicionando as mensagens que voce deseja.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    • Sugerido como Resposta Mr. Morello terça-feira, 7 de julho de 2015 14:52
    terça-feira, 7 de julho de 2015 12:55
    Moderador
  • Acho que estamos quase chegando num consenso.

    Eu vou estudar melhor sobre o NLog e os arquivos PDB (não conhecia).

    Só em relação a ultima pergunta "Em ambos os casos são duplicadas as telas e na nova o programador coloca as mensagens que ele quer verificar." é que tem um detalhe. Eu sei que dá pra duplicar as telas pra homologar, colocar as mensagens e tals, mas isso só no desenvolvimento, pelo que entendo. Se eu instalar o sistema no servidor do cliente só vai ter o arquivo .EXE que será o aplicativo pra rodar o sistema (destacado com a flecha) e outros arquivos complementares como DLL. Lá eu não vou ter cada tela pra poder debugar. Veja como fica a pasta do sistema dentro de Arquivo de Programas:

    Entendeu como não dá pra testar cada a tela na base de produção (versão instalada no cliente)? Só se for eu que não entendi alguma coisa.


    terça-feira, 7 de julho de 2015 14:24
  • Ok.. Mas no Delphi, como voce fazia para escolher qual das telas seria usada. creio que voce cria duas telas, uma normal e outra tela_debug.. Minha questao é como no Delphi voce fazia para escolher a tela_debug. Uma vez que eu entenda como voce fazia eu poderei te orientar de como fazer a mesma coisa no VS.NET.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    terça-feira, 7 de julho de 2015 17:53
    Moderador
  • Faz anos que não trabalho mais com Delphi, mas nessa IDE é gerado um arquivo executável geral e cada tela/formulário é gerado um arquivo .bpl. O arquivo executável geral serve pra carregar esses arquivos .bpl.

    Imagine que a tela de Cadastro de Clientes se chame TTB001.bpl. Daí se ocorrer erro nessa tela eu duplico esse fonte e renomeio para TTB099.bpl. Por enquanto o usuário continua usando a tela TTB001 e eu (desenvolvedor) tenho acesso a tela TTB099. Nessa nova tela eu coloco inúmeras mensagens (ShowMessage) nos métodos/procedimentos para acompanhar passo a passo até que num determinado momento encontre o erro:

    ShowMessage("passo 1");

    ShowMessage("passo 2");

    ShowMessage("passo 3");

    Ocorreu erro em alguma variável nesse intervalo. Daí coloco mais ShowMessage pra saber o valor das variáveis pra identificar o problema.

    ShowMessage("passo 4");

    Essa é a forma mais fácil de localizar erros no Delphi que eu conheço. Outros colegas da area de programação também fazem isso.

    O mesmo é feito com Oracle. A diferença é que a extensão é .fmx.

    Ficou mais claro?

    terça-feira, 7 de julho de 2015 23:21
  • Eu li a documentaçao da Embarcadero sobre BPLs:

    http://edn.embarcadero.com/article/27178

    Na verdade o Delphi e o .NET geram um executavel unico. O BPL nada mais é que uma DLL que deve ser chamada dinamicamente... Se voce quiser repoduzir o mesmo comportamento, cada formulario deve estar em um projeto (em uma DLL) a parte.

    Ainda eu nao entendo como voce fazia para "relinkar" a sua nova TTB099.bpl ao projeto.

    Repito: a mesma coisa pode ser feita em .NET, mas para isso voce vai ter que alterar o formulario e alterar o ponto em que ele é chamado.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------



    quarta-feira, 8 de julho de 2015 10:30
    Moderador
  • Eu tava conversando com um colega que trabalha com Delphi e ele falou que a empresa não gera instalador do sistema. Apenas copia a pasta com o executável geral e todos os arquivos .bpl referentes a cada tela do sistema. Já eu gero um instalador no Visual Studio e não copio arquivos dessa forma.

    Na tela principal desse sistema em Delphi tem um campo pra digitar o atalho da tela, por exemplo, TTB099, e existe um código que verifica se esse arquivo existe. Se existir, já abre ele.

    Entendeu como "relinkar" a nova tela no projeto do Delphi?

    Eu já tenho um método que converte esse atalho "TTB099" e abre o formulário no Visual Studio, só que diferente do Delphi, eu não tenho cada tela na pasta "Arquivos de Programa". Só tem o Aplicativo geral.

    Voce comentou: O BPL nada mais é que uma DLL que deve ser chamada dinamicamente... Se voce quiser repoduzir o mesmo comportamento, cada formulario deve estar em um projeto (em uma DLL) a parte.

    Então uma alternativa seria fazer arquivo DLL pra cada formulário do Visual Studio?

    quinta-feira, 9 de julho de 2015 00:54
  • Voce nao precisa criar um instalador para o .net também. Eu normalmente distribuo somente o executavel e as DLLs em um arquivo .ZIP.

    Eu entedi o que voce fazia no Delphi, mas isso so era possivel porque cada tela era uma BPL (o equivaliente DLL no .NET)

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    quinta-feira, 9 de julho de 2015 09:09
    Moderador
  • Opa.. estamos quase finalizando agora..

    Em qual pasta fica esse executavel que vc manda pro cliente? Como faz pra gerar DLL das telas e abrir elas no sistema?

    Se gerar DLL resolveria o meu caso, tipo, conseguiria criar telas pra teste na base de produção do cliente?

    E como vc faz pra atualizar o sistema no cliente?

    Obs.: Por que vc distribui somente o executavel com as DLLs e não gera instalador?
    quinta-feira, 9 de julho de 2015 11:27
  • Os escutaveis para distribuiçao sempre ficam na pasta bin/Release.

    Lembre-se que o uso de BPL no delphi nao é uma forma "standard" de trabalho. O uso de cada tela  em DLLs é possivel no .NET  mas nao é padrao tambem.

    Imagine o sequinte: voce cria uma DLL com um formulario dentro.. para chamar essa tela no executavel principal voce tem que fazer isso:

    Assembly assembly = Assembly.LoadFile("C:\\test.dll");
    Type type = assembly.GetType("test.dllTest");
    Form form = (Form)Activator.CreateInstance(type);
    form.ShowDialog(); // Or Application.Run(form)

    note que no codigo acima é esperado que a DLL tenha um classe test.dlTest.

    Note que todas as referencias sao strings, entao de forma geral vc poderia fazer:

    Assembly assembly = Assembly.LoadFile(dllPath);
    Type type = assembly.GetType(formClass);
    Form form = (Form)Activator.CreateInstance(type);
    form.ShowDialog(); // Or Application.Run(form)

    onde as variavies string dllPath e formClass contem o caminho da dll e a classe formulario.

    Desta forma, voce consegue criar uma dll com o formulario produçao e outra dll com o formulario de desenvolvimento e desta forma invoca-los de forma dynamica. Como eu disse, no delphi algo semelhante era feito, mas nao é a forma padrao.

    Lembrando tambem que eu ainda prefiro usar o NLog para traçar problemas do que este metodo.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------



    quinta-feira, 9 de julho de 2015 13:42
    Moderador
  • Eu estava testando o NLog com base nesse exemplo, e dai fiz uma simulação:

    try
    {
        string teste = "12345";
        teste = teste.Substring(8, 2);
    }
    catch (Exception erro)
    {
        Logger logger = LogManager.GetCurrentClassLogger();
        logger.ErrorException("Erro: " + erro.Message, erro);
    }

    Só que não estou achando o arquivo de log com detalhes do erro. Onde que fica?

    Como vc cria arquivo dll de cada formulario? E como faz pra criar o arquivo dllTest?

    Desculpe se estiver estendendo muito esse assunto, mas está me ajudando muito. Acho que falta pouco pra terminar.

    quinta-feira, 9 de julho de 2015 17:19
  • No exemplo o autor mostra em detalhes a configuraçao do NLog.config. A beleza deste componente é que voce pode configurar a saida de varias formas. Por exemplo, voce pode configura que os erros graves sejam enviados por email, o trace (mensagens normais) sobre um arquivo XML (ou texto, ou csv). Voce pode tambem guradar as mensagen em um banco de dados (qualquer banco de dados).. e tudo isso pode ser usado junto, ou seja,  enviar por email, armazenar no banco e em um arquivo.

    A documentaçao do NLog esta aqui:

    https://github.com/NLog/NLog/wiki (ver Configuration Reference)

    E aqui o tutorial do NLog:

    https://github.com/NLog/NLog/wiki/Tutorial

    Tudo o que voce tem a fazer é configurar o alvo (target) para o qual voce quer a saida:

    <?xml version="1.0" encoding="utf-8" ?>
    <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    
        <targets>
            <target name="logfile" xsi:type="File" fileName="file.txt" />
        </targets>
    
        <rules>
            <logger name="SomeNamespace.Component.*" minlevel="Trace" writeTo="logfile" final="true" />
            <logger name="*" minlevel="Info" writeTo="logfile" />
        </rules>
    </nlog>


    No exemplo acima a siata é um arquivo texto, mas se voce viu a documentaçao a lista de targets é muito variada:

    AspResponse - Outputs log messages through the ASP Response object.
    Chainsaw - Sends log messages to the remote instance of Chainsaw application from log4j.
    ColoredConsole - Writes log messages to the console with customizable coloring.
    Console - Writes log messages to the console.
    Database - Writes log messages to the database using an ADO.NET provider.
    Debug - Mock target - useful for testing.
    Debugger - Writes log messages to the attached managed debugger.
    EventLog - Writes log message to the Event Log.
    File - Writes log messages to one or more files.
    LogReceiverService - Sends log messages to a NLog Receiver Service (using WCF or Web Services).
    Mail - Sends log messages by email using SMTP protocol.
    Memory - Writes log messages to an ArrayList in memory for programmatic retrieval.
    MethodCall - Calls the specified static method on each log message and passes contextual parameters to it.
    Network - Sends log messages over the network.
    NLogViewer - Sends log messages to the remote instance of NLog Viewer.
    Null - Discards log messages. Used mainly for debugging and benchmarking.
    OutputDebugString - Outputs log messages through the OutputDebugString() Win32 API.
    PerfCounter - Increments specified performance counter on each write.
    Trace - Sends log messages through System.Diagnostics.Trace.
    WebService - Calls the specified web service on each log message.

    Com relaçao a DLL test, nada mais é que colocar o formulario dentro de uma dll. Voce pode copiar o codigo da seu form.cs (e os outros arquivos) dentro de um projeto Class Library


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    sexta-feira, 10 de julho de 2015 12:24
    Moderador
  • No video mostra que o arquivo NLog.xsd e NLog.config nas referencias do projeto, mas no meu só ficou o NLog (sem extensão). O local desse arquivo é "...Nome_projeto\packages\NLog.4.0.1\lib\net45\NLog.dll".

    Eu não consigo editar o arquivo .config igual ele fez. Por isso procurei no Windows todos os arquivos com o nome NLog.config, editei cada um e coloquei o mesmo código que ele, mas não gera o arquivo com dados do erro. Depois coloquei o mesmo código que o seu, mas não acho o arquivo também.

    Acho que só falta algum detalhe.

    sexta-feira, 10 de julho de 2015 13:14
  • Mas voce adicionou o pacote nlog.config a partir do nuget como o autor fez?

    http://www.nuget.org/packages/NLog.Config

    O arquivo NLOG deve ficar junto com a aplicaçao, no mesmo nivel do APP.config.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    sexta-feira, 10 de julho de 2015 13:36
    Moderador
  • Bah cara.. estava junto com o app.config mesmo. Tive que fazer duas correções e funcionou. Eu só estava olhando nas Referencias do projeto.

    Eu fiz igual o teu exemplo e gravou o seguinte:

    2015-07-10 10:58:36.2627|ERROR|NomeProjeto.Nome_Pastas.Nome_Tela|erro botao limpar: startIndex cannot be larger than length of string.
    Parameter name: startIndex

    Tipo, não mostrou que a variável teste tinha o valor 12345 e o sistema estava tentando pegar valor a partir da 8ª posição. É necessário rastrear a variável? O sistema possui inúmeros parâmetros e variáveis, como faria nesse caso?

    sexta-feira, 10 de julho de 2015 14:06
  • William, se puder só me responder essa última questão eu já vou entender melhor do Log e já encerro a thread.

    Obrigado.

    quarta-feira, 15 de julho de 2015 20:22
  • Boa tarde.

    A pergunta inicial já foi respondida?

    Se sim, criar uma nova thread com a pergunta adicional que veio após a resposta da primeira pergunta da thread.

    quarta-feira, 15 de julho de 2015 20:39
  • Para a pergunta inicial ele propôs usar o NLog, só que não to sabendo usar e não sei se é útil para o meu problema.

    Agora vou precisar abrir outra thread pra saber como usar NLog?

    quarta-feira, 15 de julho de 2015 21:10
  • Sim.
    quinta-feira, 16 de julho de 2015 20:17