eDeveloper - Componentes

Realizando chamadas entre componentes M10

Para quem está usando o eDeveloper 10 tem se confrontado com um grande problema que é a re-chamada entre componetes, ou seja, se tenho um componente A que chama o componente B este não pode chamar o componente A.

Para resolver este "pequeno" impasse seguem algumas dicas de uma solução:


Deve ser criado um Evento Global para que o componente chamado possa devolver um valor, vamos ao passos:

. No projeto A (principal) dentro do Main Program, deve ser criado um Evento Público teclando (CTRL+U) Janela Events (fig1). Conforme a figura, informe um nome para este Evento, crie um parâmetro para receber um valor e adicione o nome publico no nosso exemplo "ChamarPrograma".

. Ainda no Main Program agora devemos criar na Guia Logic o gatilho deste Evento, (CTRL+H) para criar o Event. Na coluna nome pressione F5 para informar o Evento, Type User Event ChamarPrograma. Será solicitado para criar a variável nesta parte do programa. Este recurso é interessante porque a variável estará disponível apenas quando o evento for chamado.

Com isso estamos preparados para receber a informação do componente que estamos chamando.

No projeto B (componente chamado) deve ser criada uma chamada para o Evento Público (fig3) gerado no projeto A.
Dentro de um programa na Guia logic crie um evento conforme a necessidade. dentro deste evento crie uma linha com a operação Raise Event apontando para o Public Event informando o nome deste evento, no nosso caso 'ChamarPrograma'. Na coluna Arguments informe os parâmetros que serão passados para o projeto A.

Com isso estaremos devolvendo ou chamando algum componente do projeto que iniciou a chamada.


Espero que com isso alguns probleminhas sejam resolvidos ;)

Gerenciamento de Dados - E que tal o ambiente multi-usuário?

Quando nós desenvolvemos uma aplicação para uma situação multi-usuário, na qual é possível que dois usuários acessem os mesmos dados ao mesmo tempo, a necessidade de desenvolvimento usando transações é maior.

Vamos dar uma olhada nisto com o mesmo cenário simples. Vamos assumir que Fred quer transferir os últimos $50 de sua conta poupança para sua conta corrente (isso parece familiar?), mas sua esposa Wilma está em outra agencia do banco e está sacando $50 da conta corrente para comprar as verduras da semana.

O que acontece? Neste caso, o cenário não é tão simples como possa parecer:

Fred	Wilma
Lê o total da conta poupança
Subtrai $50 da conta poupança
Lê o total da conta corrente
Soma $50 ao total da conta corrente	Lê o total da conta corrente

Ao mesmo tempo em que Wilma está verificando o saldo atual da conta corrente, a fim de sacar o dinheiro, Fred está depositando dinheiro na conta corrente.

Neste caso, ela provavelmente verá que o dinheiro ainda não foi transferido. Ela então verificará o saldo da conta poupança e o que ela verá? Está vazia (lembre que nós mencionamos que Fred está sacando os últimos $50).

O resultado agora será uma conversa zangada entre o feliz casal.

No mundo das transações, este cenário seria ligeiramente diferente. Quando o processo é executado como uma unidade lógica única, um subproduto útil disto é que quaisquer dados atualizados são bloqueados até que a transação tenha sido concluída.

Neste caso, Wilma ainda provavelmente veria que o dinheiro não teria sido transferido, e quando ela verificasse o saldo da conta poupança, ela veria que o dinheiro ainda está na conta. O telefone tocando para Fred teria um tom diferente.

Deve ser observado que os bloqueios são acumulativos dentro da transação. Por exemplo, depois de atualizar um certo registro (o qual é bloqueado como um resultado), o usuário atualiza um segundo registro. Ambos os registros são parte da transação e serão bloqueados até a transação ser ou aplicada (committed) ou cancelada (rolled back).

Supondo que Wilma decide que ao invés de ligar para Fred, ela vai transferir o dinheiro ela mesma. Mas pelo tempo que isso leva para acontecer, a transação com o Fred tenha sido completada (committed). Agora, neste caso, quando ela tentar verificar o saldo atual da conta poupança, o total já terá sido atualizado. Ela pode agora alegremente sacar o dinheiro da conta corrente.

O que de fato acontece neste caso em particular realmente depende do DBMS usado, mas o propósito aqui é dar uma simples visão das transações.

Fonte: "Data Management.pdf", arquivo acompanha a instalação do eDeveloper 10, em inglês.

Gerenciamento de Dados - Porque nós precisamos de transações?

Cada desenvolvedor de aplicação, tem o mesmo objetivo que é assegurar a integridade da base de dados.

Pode haver problemas se você não usar transações para assegurar a integridade da base de dados e isto pode ser ilustrado pelo seguinte cenário:

Um usuário, chamado Fred, quer transferir $50 de sua conta poupança para sua conta corrente. Neste caso, a matemática é simples:

Poupança = poupança - 50

Conta corrente = conta corrente + 50

O que aconteceria se houvesse uma falha de algum tipo entre as duas operações?

Neste caso, a conta poupança seria subtraída em $50, mas a conta corrente não seria atualizada. Pobre Fred ficou sem os $50 e existe também a questão do fundo perdido. Espere até a auditoria!

Nós podemos dizer que, neste exemplo, a integridade de dados está extrema prejudicada.

Se uma transação tivesse sido usada para assegurar que as duas operações fossem executadas como uma unidade lógica única, então se houvesse uma falha durante a execução deste simples processo, todo o processo teria sido abortado ou voltado ao seu estado inicial (rolled back - na linguagem SQL) e a integridade dos dados estaria preservada.

Assim o dinheiro, nas contas, retornaria ao valor inicial que estavam antes de iniciar a transação.

Aqui, eu deveria também adicionar o obvio: no cenário acima no qual parecem existir apenas duas operações, existiram realmente mais duas operações:

Ler o saldo da conta poupança

Ler o saldo da conta corrente

Isto é, sem considerar as modificações reais ao banco de dados.

Como nós podemos ver o processo aparentemente simples não é tão simples como parece.

Em resumo, desenvolvimento com transações é uma parte necessária de aplicações de dados integrados (data-bound applications).

Fonte: "Data Management.pdf", arquivo acompanha a instalação do eDeveloper 10, em inglês.

Gerenciamento de Dados - O que é uma Transação?

O que são transações? Porque nós precisamos usar transações?

Transações são partes integrantes do desenvolvimento de aplicações de dados integrados (data-bound applications). Uma chave para o desenvolvimento de aplicações no ambiente de base de dados é a habilidade de usar transações de forma otimizada para garantir a integridade de dados.

A palavra “Transação” é usada frequentemente quando falamos em aplicações SQL.
Uma transação é uma parte integral de um processo, contribuindo para a composição da aplicação como um todo, e pode ser definida como:

“... Uma unidade atômica de trabalho consistindo de um conjunto de modificações de dados a qual deve ser aplicada na sua totalidade ou abortada completamente”


Isto quer dizer que ou o processo como um todo é bem sucedido ou o processo todo falha.

Não existe meio termo. Inúmeras operações, tais como: UPDATE, DELETE e INSERT podem criar uma unidade única. Só se todas as operações são bem sucedidas, esta unidade lógica será bem sucedida.


Um processo de transação pode ser todo um processo de negócio lógico ou uma unidade menor que é parte de um processo de negócio lógico.

Fonte: "Data Management.pdf", arquivo acompanha a instalação do eDeveloper 10, em inglês.

Apresentação

Ola Pessoal!

Estamos iniciando este blog com um trabalho de apresentação da documentação referente ao eDeveloper 10, a qual acompanha a instalação do mesmo, porém o documento original é disponibilizado em inglês.

O objetivo deste blog é facilitar a vida dos "magicianos", com a tradução e publicação frequentes dos assuntos abordados nesta documentação, bem como, fornecer informações sobre experiências dos colaboradores no que se refere ao desenvolvimento e ao domínio específico da ferramenta e banco de dados.

Façam um bom uso do material e se sintam à vontade para contribuir sobre os assuntos abordados e assim enriquecer este blog.

Caso alguém tenha alguma documentação sobre os assuntos aqui abordados e a mesma esteja em inglês, por favor, nos encaminhem este material que estaremos avaliando e, se for o caso, efetuando a sua tradução.

Bom trabalho a todos!

Magic Blog Brasil

Para qualquer técnico que já ouviu falar sobre o software Magic, sabe que este é uma ferramenta RAD. Desenvolver com Magic é muito fácil, um aprendiz de programador, tira em minutos um programa de cadastro, que pode ser usado para modificar e excluir registros.

Mas o Magic não serve apenas para este simples exemplo, é possível desenvolver grandes softwares, como benchmark temos o ERP CIGAM. Na sua origem embrionária usou-se o Joiner, mas devido a necessidades de evolução optou-se por usar o Magic.

Neste Blog, tentaremos discutir um pouco mais o que é possível realizar com esta grande ferramenta de desenvolvimento.

Enjoy :)