Elber Carretoni

faz tempo que não mexo com SQLSever, mas você não conseguiria implementar dentro da trigger algo como: ... IF (SELECT COUNT(*) FROM inserted) > 0 BEGIN -- testar ser algum dos itens inseridos já está na base de dados IF (SELECT COUNT(*) FROM inserted WHERE exists(SELECT 1 FROM <tabela> WHERE <tabela>.<campo> =inserted.<campo>)) > 0 BEGIN RAISERROR('Um item já existe. Inclusão cancelada.',16,1); -- gera uma exceção personalizada ROLLBACK; -- desfaz qualquer ação na transação corrente RETURN; -- evita que linhas posteriores sejam executadas END END lembro-me que a trigger não é disparada para cada item incluído, assim se faz necessário tratar inserted como uma possível lista de linhas. Se este exemplo puder ser implementado, ele estará cancelando a inclusão de todas as linhas, mesmo que apenas uma já exista. Mas, se isto não for desejado, então teria que ser implementado algum tipo de loop (se não estou enganado utilizando cursor) para avaliar cada item da lista em inserted Espero ter colaborado. Micheus...a trigger é sim disparada para cada item inserido... toda vez que você executar um insert, a trigger inserted irá disparar com ctz... não entendi perfeitamente sua referência por 'lembro-me que a trigger não é disparada para cada item incluído, assim se faz necessária tratar inserted como uma possível lista de linhas'. Logo depois que a trigger terminar seu processo de execução, todos os itens (somente 1) que estiver em inserted será excluído...é como tratar inserted como uma variável table temporária, que se auto-elimina no fim do procedimento... estou certo? corrija-me se não, por favor... caso vá trabalhar com cursores, aconselho que não o faça... cursores são problemáticos, e apesar de, na minha opnião, serem mais 'delicados' para trabalhar, geralmente não conseguem dissernir uma sessão de outra, inutilizando a definição de cursor local e cursor global. Caso necessite realmente trabalhar com uma variável mutidimensional, trabalhe com uma VARIAVEL TABLE, resgatando seus valores linha por linha através de um campo identity... bom, é minha opnião... analise cada caso e retorne os resultados... Abraços a todos!

Jr...conforme e-mail encaminho à mim, fiz o que você pediu... Entretanto, o que o Malj falow deve ser considerado...se você determinar com exatidão que o terceiro e o quarto caractere serão sempre informativos da polegada, tudo bem...mas, se você não tiver essa exatidão, ae já complica. Por exemplo, a quantidade de caracteres de 01 para 100 é diferente, entendeu? neste exemplo, se eu fosse determinar que somente dois caracteres serão as polegadas do meu campo código, o 100 ficaria como 10, e não verdadeiramente 100...certo? Bom...fiz um exemplo e posso te mandar por e-mail.. entretanto, pense nisso, e se for o caso, ajuste a quantidade de caracteres no campo código para deixá-los sempre com a mesma quantidade...ae sim funciona bem! Abraços,

Hummm...bem estranha essa análise Barboza... qual seria o objetivo de transferir os dados de uma tabela? você quer deixar o formulário com uma tabela diferente somente para o usuário não ver os dados anteriores cadastrados? Sendo assim, a tabela do formulário sempre ficaria vazia? Explique melhor para que possamos de ajudar...

discagem?

ixi, também to correndo atrás disso...rsrs se você descobrir, poste, por favor... quando eu descobrir também posto aqui... abraços,

Gesiel, muito obrigado pela resposta... concordo plenamento que o aninhamento de chamadas através de triggers pode ser um problema imenso... Entretanto, através da análise que fiz, nenhuma tabela será aninhada entre si, somente uma tabela do sistema será aninhada à execução de todas as outras tabelas, visto que também na procedure não há nenhuma chamada em qualquer ação gatilho que dispararia a execução de determinada trigger que poderia causar um inferno aninhado no banco de dados! Na verdade, estou precisando criar um sistema que necessita de versionalização de registros do banco de dados, onde toda alteração acresce o número da versão e mantém o registro antigo, antes de ser alterado...estou criando todo este processo via bd, já que fazer isso pelo front-end seria tremendamente terrível... Agradeço pela atenção, apoio e pela boa vontade! Abração Gesiel!

Eu so quero que o sub formulário, carregue as linhas dos que não estão liquidados. Morrisson, subformulários são geralmente formulários internos que de uma maneira ou outra dizem a respeito de informações do formulário principal! (foi o que o Malj falow, se não me engano!) De qualquer maneira, isso não é uma regra e você pode efetuar excessões sim, já que é você quem determina a usabilidade do seu sistema... Um formulário também apresenta uma fonte de controle, da mesma forma que o formulário principal...sendo assim, crie uma consulta que traga todos os registros não validados (no critério do campo validado, coloque a expressão parecida com a que você utiliza na macro)...posteriormente, coloque um subformulário totalmente independente do seu formulário principal e indique como fonte de controle deste a consulta criada... Deu pra entender? Retorne os resultados! Abraços,

Gteubl, neste caso você poderia fazer um relatório do access agrupado por região, sendo que dentro de cada região haveria a contagem do número de ocorrências respectivas... um botão no formulário que abre este relatório com todos os dados atualizados na tela... da mesma forma que o excel, o access também atualiza-se conforme a entrada de registros no banco de dados...aliás, posso te garantir que o access é muito mais eficiente pra isso, já que estamos falando de gerenciamento de banco de dados... De qualquer forma, se você ainda quiser seus gráficos e relatórios em access, é bem fácil fazer uma exportação dos dados do access para o excel, gerando relatórios automaticamente conforme as filtragens que você também quiser. Dessa forma você teria o máximo controle dos seus dados através do access, sem perder a repercusão do seus relatórios em excel... bom, falando neste momento somente em access, um formulário/relatório tem sempre uma fonte de controle, que pode ser uma tabela/consulta... aconselho a você que faça um relatório em access que mostre a contagem de registros por, como no seu exemplo, região...pra isso então, você deve fazer como fonte de controle de um relatório uma consulta totalizadora, que faça a contagem de registros por região, conforme o número de ocorrências... se não souber como criar uma consulta totalizadora, retorne o post para que possamos te ajudar melhor... Abração,

eu acho mais fácil e mais eficiente mesmo definir a ordem de tabulação hein...rsrs

Murilo, pra isso você tem várias propriedades: .BorderColor -> Muda a cor da borda de um objeto; .ForeColor -> Muda a cor da fonte (texto) de um objeto; .BackColor -> Muda a cor de fundo de um objeto; Sendo assim, no evento ao clicar no seu botão de opção, você pode aplicar: Me.ObjetoRetangulo.BorderColor = 255 Me.ObjetoRetangulo.ForeColor = 0 Me.ObjetoRetangulo.BackColor = 16548 como pode ver, você pode determinar a cor por números seriais... certo? retorne os resultados...abraços!

ixi, isso é bem discutido entre o pessoal... infelizmente acredito que não...acho que será bem difícil você encontrar um 'InstalShield' que gere um executável do Access... Baixei um RunTime do Access aqui, entretanto não testei ainda...se quiser, envio por e-mail depois...Porém também não sei a qual versão do access este run time se refere... O que você pode fazer é publicar o mdb em mde...por enquanto acredito que seja o único método mais fácil e aplicável no momento...

hummm... DoCmd.OpenQuery, "Ajuste_Exportacao", acViewNormal acho que isso vai resolver o que você quer... se não é isso, retorne a dúvida aí... Resolveu sim, porém tem como tirarar as menssagens de execução das querrys?. Aparece a menssagem "You are about to run a make table query that will modify data in your table" com botões Yes, No e Help. Eu gostaria que essa menssagem não aparecesse, que o usuário final não percebesse que está sendo executada uma querry toda vez que o formulário é aberto. é possivel? Abraços Docmd.SetWarnings False Docmd.OpenQuery... Docmd.SetWarnings True

hummm... DoCmd.OpenQuery, "Ajuste_Exportacao", acViewNormal acho que isso vai resolver o que você quer... se não é isso, retorne a dúvida aí...

Obaars, como assim executar uma query? Qual seria a função de executar uma query no evento ao abrir de um formulário? Há possibilidades de alterar a SQL de consulta... com ctz deve haver sim maneiras de criar uma query virtual por comando...porém até agora não encontrei essa necessidade... Destrinche sua dúvida melhor para que possamos tentar ajudar! Abraços,

Pessoal... Tenho um banco de dados que necessita de muitas triggers. Sendo assim, estarei criando somente uma Procedure que faça todas as funções do banco de dados, e então criaria triggers somente para chamar a execução da Procedure... Gostaria de saber qual a melhor maneira de criar essa procedure? Esse seria o meio mais indicado? Enfim...é a primeira vez que terei de aplicar este conceito e gostaria de pedir gentilmente o apoio do pessoal mais experiente... Abraço a todos!