Ir ao conteúdo
  • Cadastre-se

Clemente Silva

Membros Plenos
  • Total de itens

    2.467
  • Registro em

  • Última visita

  • Qualificações

    0%

Reputação

7

Sobre Clemente Silva

  • Data de Nascimento 16-08-1972 (46 anos)

Informações gerais

  • Cidade e Estado
    Campinas, SP

Outros

  • Ocupação
    Programador
  • Interesses
    Desenv. Sistemas, Hardware, Games, etc...
  1. Faltam informações: - Qual banco de dados? - Qual s.o.? - Config do computador? Se for Windows 98, instale a versão 2.5 do MDAC, pois tinha um bug do MSJet que disparava este erro, o qual foi corrigido nesta versão.
  2. "Handle" em Visual Basic, ou é a identificação da classe (propriedade "Hwnd") que te permite manipular uma janela de qualquer aplicação através da sua aplicação, ou então é o contexto de dispositivo (propriedade "HDc"), que te permite basicamente o mesmo que o "Hwnd", porém estende-se a tudo o mais que estiver dentro da classe (propriedades, métodos, etc...). Isso não serviria para o que você pretende fazer, pois não se trata de acesso direto a memória, mas sim de objetos que estão residentes na memória. A diferença é que você vai estar recuperando apenas os dados que os objetos deixam você pegar, e não todo aquele "raw data" que está na memória. Você tem que acessar o objeto da forma como o Windows permite fazer (APIs)... Quanto ao que pretende, você pode fazer um acesso direto a memória a partir do ambiente de sua aplicação e manipular dados da mesma; porém eu desconheço se existe um modo de "hackear" dados de outras aplicações que estejam em memória. Mas em qualquer das duas situações, provavelmente você vai conseguir mais GPFs do que resultados satisfatórios, isso porque é o Windows quem não vai te deixar acessar isso, pelo menos não tão facilmente, ainda mais com uma linguagem feita para RAD, como é o VB... Ainda, ao tentar acessar endereços de memória com VB, o mais provável é que consiga fazer a IDE travar ou simplesmente fechar a todo momento, já que a IDE do VB não tem suporte adequado pra esse tipo de trabalho. Se quiser ver um exemplo de DMA com VB, veja nesse link: http://edais.mvps.org/Tutorials/Memory/Memch1.html
  3. Não tem, o 'Jet SQL Engine' do Access é muito limitado, é só o basicão... quem quiser fazer algo assim tem que fazer 'gambiarra'. ... Italiano, então você quer mesmo é fazer essa coluna do total... ok, isso é bem simples. 1) Antes de inserir um novo registro, execute um SELECT LAST na coluna do acumulado, para pegar o valor acumulado atual Ex.: SELECT LAST(SumOFTotal_) AS Acumulado FROM Class; Suponto que o resultado aqui tenha sido 1.000,00 2) Depois execute sua instrução INSERT INTO para inserir um novo registro, e quando for inserir o valor do acumulado, some o acumulado atual com o valor do cliente atual. Ex.: INSERT INTO Class (Cliente, Total_, SumOfTotal_) VALUES ('Fulano', 350,00, 1.000,00+350,00); É por aí (eu acho), agora o resto é contigo
  4. "Run-time error 9" deve ser algum array ou array de controles que está referenciando um índice que não existe (subscript out of range). Solução: 1) Veja com o cliente em que momento exatamente isso acontece, qual botão ele clica, o que o sistema está executando no momento do erro, etc... 2) Isso vai te ajudar a identificar no código onde isso está acontecendo, então coloque um tratamento de erros em cada rotina dentro dos Forms e Módulos envolvidos no processo, pois o erro pode estar acontecendo em um Módulo e ssendo disparado num Form, e vice versa... Não acho que o erro tenha a ver com sistema operacional, isso pode ser muito bem uma coincidência. E outra, não tem testador de software melhor que o usuário leigo, eles acham (ou inventam) erros que nós jamais seríamos capazes de achar
  5. Pérai, vamos recapitular tudo de novo, que agora eu já me perdi Vamos colocar o problema novamente: - Você tem clientes: FULANO, BELTRANO, CICRANO, etc... - Você tem a soma de todas as vendas feitas para esses clientes, que é a "receita" VENDAS DE FULANO + VENDAS DE BELTRANO, + VENDAS DE CICRANO + ... = RECEITA - Você quer saber quais são os clientes cuja soma dos valores das vendas seja MAIOR OU IGUAL A 80% DA RECEITA. Então, vamos fazer assim: TABELA_VENDAS -------------------------- NOME_CLIENTE | VALOR_VENDA -------------------------- FULANO 3.500,00 BELTRANO 200,00 CICRANO 150,00 FULANO 2.000,00 -------------------------- RECEITA 5.850,00 Ok, então 80% de 5.850,00 seriam 4.680,00, logo numa consulta dessas, somete o FULANO iria aparecer, pois a soma de suas receitas é 5.500,00, sendo mais que os 80% to total, certo? Transformando isso num algoritmo, teríamos: SELECIONE CLIENTES ONDE SOMA INDIVIDUAL DE SUAS RECEITAS SEJA MAIOR OU IGUAL À RECEITA TOTAL Vamos aos fatos: 1) A ideia de uma coluna para colocar o acumulado seria interessante, não fosse o fato de ser extremamente trabalhoso manter esse total além de ser passível de erro e tornar o sistema lento. Motivo: teria que buscar sempre o ultimo registro, pegar o último total e somar com o valor do registro atual. Isso num sistema em rede com N máquinas jamais funcionaria. 2) Você não pode incluir a coluna NOME_CLIENTE na consulta se quiser fazer a soma da coluna VALOR_VENDA Motivo: o agrupamento feito por NOME_CLIENTE não deixará chegar a um total geral, mas sim apenas a totais por cliente. 3) Pelo fato 2 acima, não dá pra fazer tudo numa consulta só. ... Agora vamos a uma provável solução: 1) Você tem que fazer uma consulta para levantar o total de receita no momento: SELECT SUM(VALOR_VENDA) AS RECEITA FROM TABELA_VENDAS; 2) Dessa consulta, calcule os 80% (ou o percentual que quiser) 3) Então execute outra consulta, assim: SELECT NOME_CLIENTE FROM TABELA_VENDAS GROUP BY NOME_CLIENTE HAVING (SUM(VALOR_VENDA)>=4.680,00); Pronto. Agora já posso ir dormir.
  6. Qual a linguagem? Se for em VB, use o evento OLEDragDrop de algum comtrole, por exemplo, um ListBox. Coloque também a propriedade "OLEDropMode" do controle para "1 - Manual" Aí pode usar um código assim: Private Sub List1_OLEDragDrop(Data As DataObject, Effect As Long, Button As Integer, Shift As Integer, X As Single, Y As Single) Dim Arquivo For Each Arquivo In Data.Files If LCase$(Right$(Arquivo, 3)) = "mp3" Then List1.AddItem Arquivo Next End Sub
  7. Mas é aí que está o problema, a cláusula "GROUP BY" é justamente a que faz o agrupamento do qual eu estava falando. E o erro aconteceu na cláusula "HAVING" pois tanto esta como a "WHERE" não permitem cálculos, a não ser que sejam feitos em conjunto com funções agregadas, e ainda em determinadas condições. Eu acho que o ideal é você obter primeiro os 80% do total do faturamento numa primeira consulta, e depois usar esse valor como critério na consulta que pretende fazer. Aí nem precisa trazer o campo "Class.SumOFTotal_", coloque uma cláusula "WHERE" mais ou menos assim: WHERE (SUM(Class.TOTAL_) >= VALOR_OBTIDO_NA_PRIMEIRA_CONSULTA ); Em tempo, esse campo "Class.SumOFTotal_", para quê ele serve? Você mantem a soma atualizada de todo o faturamento nele?
  8. Bom, se o seu problema já está resolvido, então está ótimo, mas... daí a dizer que dá pra pegar a senha de usuário do Windows por uma simples biblioteca de objetos do Exchange, isso eu realmente gostaria de ver funcionando. Seria uma bomba histórica sobre a cabeça do tio Gates um buraco tão grande na segurança... Gente, tá certo que a MS não é lá essas coisas e que a segurança dos produtos deles é bem falha, mas será que eles iriam deixar um rombo assim tão fácil de descobrir? Isso já teria sido explorado há muuuuuuito tempo atrás, se existisse. Mas, veja o que você consegue descobrir, de repente... nada é impossível
  9. Eduardo, a instrução "TOP PERCENT" existe também no engine "Jet SQL" usado pelo Access, mas nesse caso ela retornaria um percentual do total de registros, ou seja: ela não vai usar como critério o cálculo do percentual de um determinado campo, como quer o colega Italiano. Quanto ao problema do colega, só não entendi uma coisa: é pra mostrar os clientes cuja receita representa 80% de todo o faturamento? Se é assim, aí complica, pois teria que fazer 2 consultas: primeiro fazer uma consulta para levantar o total do faturamento e calcular os 80% (fácil) e depois aí sim fazer outra filtrando os clientes cuja soma alcançam esse valor (fácil também). Não dá pra fazer tudo numa consulta só, pelo seguinte: se você for usar uma função agregada "SUM" no campo que tem os valores, e também adicionar o campo de clientes na consulta, o engine do SQL vai primeiro agrupar todos os clientes iguais, e depois retornar a soma por cliente. Aí poderia fazer algo assim: SELECT Cliente, Venda, Acumulado FROM Tabela GROUP BY Cliente, Venda, Acumulado HAVING (Acumulado>=(Sum(Acumulado)*0.8)); Então se você for calcular percentual desse resultado, vai estar calculando sobre o total do cliente, e não do faturamento total. É por isso que primeiro você tem que obter o total do faturamento primeiro, em uma consulta separada. Acho que é isso...
  10. A grosso modo, ela gera uma imagem. É como se fosse um scanner, porém ele "escaneia" impressões digitais. Não é nada comparado a um leitor de código de barras, o qual apenas lê uma imagem padronizada e pré-formatada, e a "traduz" em números. Biometria é bem mais complexo que isto, então se você abrir o bloco de notas e usar o leitor de impressão digital, nada vai acontecer. É preciso que um aplicativo escrito especialmente para esse tipo de aparelho faça a leitura e a gravação, e posteriormente o processamento dos dados para comparação. Para Windows, existem componentes ActiveX com os quais você pode desenvolver aplicações para usar biometria, eu já postei isso em alguns tópicos, use a pesquisa que você encontra. Para Linux, se não me engano também já tem um componente, nesse caso procure no SourceForge.
  11. Impossível não é, porém isso é hacking... e sendo assim, vai ser bem difícil encontrar algo. Deve existir API para isso, mas ou não está documentada, ou como eu já disse, vai ser bem difícil achar. Se fosse tão fácil, seria "um tiro de misericórdia" na já agonizante pseudo-segurança do Windows. Acho que o correto seria você criar uma janela de configurações onde o usuário pudesse ele mesmo colocar a senha, para que o seu programa possa usá-la para o propósito que você descreveu.
  12. Solução: na rotina "btponto_onclick", basta trocar o ponto por vírgula. Motivo: configurações regionais para o Brasil (Ponto é separador de milhar, Vírgula é casa decimal)
  13. Relaxe, provavelmente isto não tem nada a ver com seu HD. Veja aqui como proceder: http://support.microsoft.com/kb/330174/pt-br Ou ainda, pode ser que seja por causa de um bug do SP2 (mais um) http://support.microsoft.com/kb/885464/pt-br
  14. Não manjo muito de Access e não sei como está fazendo as rotinas de gravação, mas tem que dar um jeito de quando for gravar SAÍDA na tabela de movimentos, que grave a quantidade NEGATIVA. Por exemplo, supondo que você vá lançar: ENTRADA de 10 botas SAÍDA de 5 botas A quantidade "10" você grava como entrada, positivo. Simplesmente "10". Já a quantidade "5" você deve gravar na tabela como NEGATIVO: "-5" Depois é só fazer a soma por produto, e os numeros negativos automaticamente vão se subtrair dos positivos. É dessa soma que você obtém o saldo. Eu por exemplo executo uma instrução SQL mandando somar o campo de quantidade (que vai ter valores positivos e negativos) passando o ID do produto como parâmetro. Note que não importa como o usuário digite na tela, nem como você vai apresentar em relatório, etc... o que importa é como vai gravar. Para mostrar na tela, você pode simplesmente suprimir o sinal negativo depois, se quiser.
  15. Vou tentar ajudar, é um assunto um tanto complexo, mas como a insônia me atacou hoje, vamos lá... Vamos primeiro categorizar suas tabelas entre Cadastros e Movimentos: CADASTROS: 1) Produtos 2) Grupos 3) Subgrupos 4) Fornecedores MOVIMENTOS: 1) Entrada 2) Saida Aqui nos movimentos percebe-se que já começa errado: você não deveria ter uma tabela para entradas e outra para saídas, pois isso vai tornar muito difícil quando você precisar obter saldos, relatórios, etc... Ao invés disso, você deveria ter APENAS uma tabela para ambos os tipos de movimento (ENTRADA e SAÍDA), com um campo para diferenciar o tipo de lançamento. Este campo marcaria se o registro é ENTRADA ou se é SAÍDA, e serve inclusive como um filtro para consultas. ... Agora vamos aos relacionamentos. Nos CADASTROS, toda tabela deve ter um ID, um campo que defina unicamente cada registro. Pode ser um campo "Auto Numeração", e deve ser chave primária. É por esses campos que você vai fazer todos os relacionamentos entre as tabelas. Por exemplo: FORNECEDORES - Campo ID_FORNECEDOR ------------------------- SUBGRUPOS - Campo ID_SUBGRUPO (Chave Primária) - Campo ID_GRUPO Cada "ID_SUBGRUPO" deve pertencer a um "ID_GRUPO", de modo que em uma consulta: - a cada "ID_SUBGRUPO" selecionado, virá o "ID_GRUPO" ao qual pertence. - a cada "ID_GRUPO" selecionado, virão todos os "ID_SUBGRUPO" relacionados Note que isso resolveria o problema que você descreveu quanto a selecionar um grupo para puxar os subgrupos... ------------------------- GRUPOS - Campo ID_GRUPO (Chave Primária) ------------------------- PRODUTOS - Campo ID_PRODUTO (Chave Primária) - Campo ID_SUBGRUPO - Campo ID_FORNECEDOR Cada "ID_PRODUTO" deve pertencer a um "ID_SUBGRUPO" bem como a um "ID_FORNECEDOR", de modo que, em uma consulta: - a cada "ID_PRODUTO" selecionado, virá o "ID_SUBGRUPO" ao qual pertence, bem como o "ID_GRUPO", e ainda o "ID_FORNECEDOR". - a cada "ID_SUBGRUPO" selecionado, virão todos os "ID_PRODUTO" relacionados. - a cada "ID_GRUPO" selecionado, virão todos os "ID_SUBGRUPO" relacionados, e consequentemente todos os "ID_PRODUTO" relacionados a cada um dos "ID_SUBGRUPO". - a cada "ID_FORNECEDOR" selecionado, virão todos os "ID_PRODUTO" relacionados. ------------------------- Você deve relacionar assim: GRUPOS.ID_GRUPO -> um para muitos com -> SUBGRUPOS.ID_GRUPO SUBGRUPOS.ID_SUBGRUPO -> um para muitos com -> PRODUTOS.ID_SUBGRUPO FORNECEDOR.ID_FORNECEDOR -> um para muitos com -> PRODUTOS.ID_FORNECEDOR ------------------------- Finalmente a tabela de movimentos, deve conter o campo ID_PRODUTO apenas, nada mais que isso. Tudo o mais jáa está contido nas outras tabelas, portanto basta puxar o que precisar paara efeito de consultas. O relacionamento seria: PRODUTOS.ID_PRODUTO -> um para muitos com -> MOVIMENTOS.ID_PRODUTO Bom, acho que é mais ou menos por aí...

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas publicações sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×