Aumentando a memória da JVM
-Xms256m -Xmx512m
DataGrid com ItemRender de CheckBox – Solução
Bloquear a execução de scripts nas tabelas e forçar o usuário a usar a aplicação - Oracle
CREATE OR REPLACE TRIGGER nome_trigger_001
BEFORE INSERT OR DELETE OR UPDATE
ON nome_tabela
REFERENCING NEW AS NEW OLD AS OLD
BEGIN
IF(USER <> nome_usuario_aplicacao)THEN
RAISE_APPLICATION_ERROR(-20001,'Só é possível INSERIR, ALTERAR OU EXCLUIR os registros pela aplicação.');
END IF;
END;
Oracle - Trigger
Post muito bom sobre criação e comandos para manipular trigger.
Ex:
SELECT trigger_name, trigger_type, triggering_event, table_name, referencing_names, status, trigger_body
FROM user_triggers
WHERE trigger_name = 'nome_da_trigger';
http://www.linhadecodigo.com.br/Artigo.aspx?id=322
Configuração de pool de conexões Oracle 10g em Java para balanceamento de carga
JavaMail: Enviando um email com conteúdo HTML
Java Persistence 2.0 Final Release Is Now Available
Os 13 Comportamentos de Liderança de um Arquiteto de Software em Projetos
Adiando as restrições no Banco de Dados - Deferred Constraints
Freqüentemente nos deparamos com a seguinte situação em aplicações suportadas por SGBDs: em grandes transações envolvendo múltiplas dependências entre as tabelas é difícil processar os dados eficientemente devido às restrições impostas pelas constraints. Um exemplo disso seria a atualização de uma chave primária (PK) referenciada por uma ou várias chaves estrangeiras (FK). As colunas que compõem a chave primária não podem ser atualizadas uma vez que deixariam órfãs as tabelas dependentes e estas também não podem ser atualizadas sem que antes haja uma chave primária a ser referenciada. Tradicionalmente este problema era resolvido de duas maneiras ardilosas: desabilitando-se temporariamente as constraints de chave estrangeira ou excluindo-se os registros originais e recriando-os em seguida com os novos valores. Uma vez que nenhuma destas soluções é particularmente satisfatória, SGBDs como Oracle, a partir de sua versão 8.0, e PostgreSQL, a partir de sua versão 7.3, introduziram um poderoso mecanismo para tratar essa questão: as restrições adiáveis (“deferred constraints”).
As restrições adiáveis
No comportamento padrão do PostgreSQL, as constraints de uma tabela são verificadas a cada instrução DML de alteração (INSERT, UPDATE ou DELETE). A idéia fundamental das deferred constraints consiste, como o nome diz, em adiar as verificações. Com isso, uma restrição adiável é validada apenas ao final da transação, no evento COMMIT. Apesar de o padrão SQL contemplar restrições adiáveis de qualquer tipo, o PostgreSQL limita-se às restrições de chave estrangeira (“foreign key constraints”). Restrições do tipo CHECK e UNIQUE não são adiáveis neste SGBD.
Ao ser criada, uma restrição de chave estrangeira pode ter uma das três características. A opção default é NOT DEFERRABLE (não adiável em qualquer hipótese), mas este comportamento pode ser mudado se usada a opção DEFERRABLE (adiável). Sendo adiável, a validação inicialmente pode ocorrer de imediato (INITIALLY IMMEDIATE) ou ao final do processo (INITIALLY DEFERRED).
Flex3 + Lcds + EJB3 (Giuliano Bortolassi)
Post que fala sobre a integração do Flex3+Data Services+EJB3
(http://www.giulianobortolassi.com/2008/07/flex3-lcds-ejb3.html)
Visitantes
Consulta de CEP
|
