TAG | PL/SQL
Uma coisa incomoda e muito boa parte dos desenvolvedores, é o de prestar manutenção em um software já pronto e que foi desenvolvido por outra equipe/pessoa.
Isso ocorre, pois além de uma linha de raciocínio diferente também temos o fator de códigos muitas vezes elaborados de forma duvidosa, com pouca ou nenhuma padronização o que torna a sua compreensão por terceiros difícil além do fato que se o projeto do software for mal estruturado a sua manutenção é uma verdadeira tortura.
Deixemos de lado (por enquanto) o aspecto de desenvolvimento de novos recursos e vamos nos concentrar na parte mais maçante e cansativa para o desenvolvedor: a localização e correção de erros.
Para isso posso deixar algumas dicas:
O primeiro passo é conhecer o processo, é claro que você como desenvolvedor não precisa conhecer todos os processos, pois em um ambiente de grande porte isto é impossível, mas você precisa com certeza conversar muito com o usuário, não apenas o que relatou o erro, mas os usuários das outras áreas envolvidas, isso irá lhe permitir saber de antemão se o erro é realmente um erro de software, uma regra mal formada na definição durante o ciclo de desenvolvimento daquele software ou ainda uma mera má interpretação do usuário.
Caso seja mesmo um erro de software e é aqui que a minha dica se concentra, vou considerar então que você está utilizando o Oracle Forms, você deve em primeiro lugar interpretar o tipo do erro:
Caso seja uma mensagem de erro customizada, ou seja, aquela mensagem de erro mais amigável que você embute no seu software será necessário localizar em todo o Form qual o ponto de chamada para poder localizar o ponto exato do erro.
Caso seja um erro padrão do Oracle (seja um ORA, FRM, REL, etc) você pode anotar o código e procurar no Google ou na base de conhecimento para descobrir a causa e as possíveis ações de correção. Uma dica interessante é que no momento da execução, junto com o usuário mesmo, você pode acionar SHIFT + F1 e irá obter a descrição do erro e isso é bem útil em casos de erros em updates ou inserts que a sua aplicação pode precisar realizar.
E ainda caso o erro apresentado seja um FK, UK ou PK você pode varrer todo o banco, utilizar o PL/SQL Developer, por exemplo, procurando o ponto que esse recurso está para poder modular e corrigir o erro.
Corrigir erro é chato, mas é necessário fazer e seguinte os passos acima a tarefa de detectar erros e corrigi-los no Oracle Forms se torna menos maçante e mais produtivo.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
Leia mais:
Volto a afirmar que todo bom desenvolvedor acompanha e segue todas as best pratices de sua ferramenta de trabalho, no meu caso a Oracle divulga as suas e também a Sun divulga os Blue Prints para o Java.
Mesmo que para o cliente que muitas vezes não tem conhecimento técnico é importante seguir tais práticas, mesmo que no inicio do projeto isso consuma um esforço maior, mas no final você vai ganhar muito e listo alguns motivos para isso:
- A sua aplicação ganha em performance e usabilidade;
- Maior transparência para o cliente;
- Suporte, manutenção e upgrades de forma fácil, precisa e direta;
- Maior credibilidade junto ao cliente técnico.
Ou seja, a menos que você venda a sua solução e depois desapareça do mercado não é negócio nenhum fazer um desenvolvimento atrapalhado, pois em um futuro próximo você mesmo terá retrabalho para dar manutenção e atualização em sua solução.
Também não quero dizer que você precisa saber todas as minúcias, mas pelo menos o trivial é sua obrigação.
Um exemplo prático, vamos supor que você precise realizar uma consulta em uma tabela e guardar os dados em uma variável, dentro do Forms Oracle:
SELECT campo INTO variavel FROM tabela
Correto o código acima?
Sim e não.
Sim porque vai funcionar.
E não pois violou uma best pratice do Oracle, que é colocar tudo dentro de um cursor, mesmo que retorne apenas um resultado.
Essa recomendação existe pois em algum momento sua aplicação pode perder performance com isso.
Leia mais:
11
Porque utilizar padrões em projetos de software
Sem comentários · Post por Petter Rafael em Java, Oracle, PHP
Algumas vezes quando estamos desenvolvendo algum software nos perguntamos o porque de ter tanto trabalho para obedecer padrões, seja qual for a linguagem utilizada (Java, PL/SQL, PHP, etc).
Vou dar um exemplo prático.
É uma recomendação, ou best pratice, como preferir, que todo início de script em PHP seja iniciado com:
<?phpPorém, caso o seu php.ini esteja configurado para obter compatibilidade com a sintexe do ASP é possível iniciar um script assim:
<?O problema aqui é que nas últimas versões do PHP a prática de compatibilidade com o ASP tem sido deixada de lado e você ao migrar seu servidor para uma versão mais nova do PHP terá problemas e vai ter que atualizar todos os seus scripts.
Notaram o porque da importância em seguir padrões? Principalmente se estes padrões foram incentivados pela própria desenvolvedora da ferramenta.
Um outro caso, agora falando em Java.
Por ser utilizado para projetos mais complexos, a obediência de padrões em Java deve ser seguida a risca senão a manutenção do seu código-fonte passa a ser uma tarefa impossível.
Um caso clássico é o acesso a dados, mesmo que você não utilize um framework para isso é recomendado que ao utilizar JDBC seja utilizado também DAO (Data Acess Object) para facilitar a manutenção futura do seu projeto, senão será tanto SQL espalhado dentro do seu código que de orientado a objeto vai parecer orientado a string.
Leia mais:
30
Segredo na instalação do PL/SQL Developer
Sem comentários · Post por Petter Rafael em Oracle
Uma boa parte dos desenvolvedores Oracle, principalmente aqueles que trabalham com PL/SQL, prefere utilizar como IDE o PL/SQL Developer e existe uma espécie de pegadinha na sua instalação.
Quando a instalação é executada em um ambiente de 32 bits tudo ocorre bem, porém em ambientes 64 bits ocorre um pequeno problema que carece de atenção.
No Windows, por padrão, os softwares aplicativos são instalados na pasta Arquivos de programa, porém em um Windows 64 bits existe duas pastas para softwares 64 bits a pasta padrão é a Arquivos de programa, porém para softwares 32 bits que serão executados sob uma camada de compatibilidade e a pasta padrão é a Arquivos de programa (x86) e aí é que está o problema.
O PL/SQL Developer não funciona adequadamente se o path com a instalação contiver caracteres como o ( ), ou seja, alguma coisa internamente no software perde a conexão com o Oracle e se o PL/SQL Developer for instalado dessa forma ao tentar conectar dispara um erro de perda de conexão com o banco de dados Oracle.
A solução para isso é desinstalar o PL/SQL Developer e proceder a instalação em uma pasta sem caracteres especiais.
Leia mais:
Pesquisando alguns códigos PL/SQL que eu tinha guardado em meu computador, achei um bem interessante, nem me lembro quando foi que o utilizei, porém o pequeno trecho de código PL/SQL fornece uma visão mensal em forma de calendário de acordo com o mês e ano informado como parâmetro.
Segue o código:
SELECT segunda, terca, quarta, quinta, sexta, sabado, domingo FROM (SELECT MIN(DECODE(sem,1,d)) segunda, MIN(DECODE(sem,2,d)) terca, MIN(DECODE(sem,3,d)) quarta, MIN(DECODE(sem,4,d)) quinta, MIN(DECODE(sem,5,d)) sexta, MIN(DECODE(sem,6,d)) sabado, MIN(DECODE(sem,7,d)) domingo, d-sem semana FROM (SELECT DECODE(TO_NUMBER(TO_CHAR(TO_DATE(LEVEL||'/'||:p_mes_ano,'dd/mm/yyyy'),'d')),1,7,TO_NUMBER(TO_CHAR(TO_DATE(LEVEL||'/'||:p_mes_ano,'dd/mm/yyyy'),'d'))-1) sem, LEVEL d FROM dual CONNECT BY LEVEL <= TO_NUMBER(TO_CHAR(LAST_DAY(TO_DATE(:p_mes_ano,'mm/yyyy')),'dd')) ) GROUP BY d-sem ORDER BY semana)
O código é simples, didático (fácil de compreender e alterar) e pode ser utilizado para formar calendários em suas aplicações Oracle.
