Micheus

Bom, neste caso... Observe que você inicializa -> SQLCondicao := ''; e não muda ela antes de chegar no -> if SQLCondicao = '' then logo, este if será sempre validado. O if anterior -> if ((TxtDtVenIni.Text <> ' / / ') or (TxtDtVenFin.Text <> ' / / ')) then está permitindo que um dos valores seja nulo, porque você está usando um OR e não um AND. A menos que você possa realmente informar apenas uma data no período, isto deveria ser corrigido. Neste caso, a montagem da string (concatenação) deveria levar isto em conta, pois se uma das datas pode ser nula, então ela não deveria ser incluída no filtro. Voce provavelmente estaria filtrando um perído (between), ou datas maiores que a inicial (>=) ou as menores que a final (<=) Dê uma avaliada nisto. Como voce tem todas as informações em uma única tabela, no meu entender, é desnecessário muito do que você está usando.Basicamente a sua consulta é apenas esta: Select A.CodCli, A.NomCli, A.Parcela, A.Vencimento, A.Receber, A.Recebido, A.Valor From Contas_Receber A where A.Vencimento Between <dd.mm.yyyy> and <dd.mm.yyyy> order by A.NomCli Em uma modelagem de dados usual, as informações do cliente estariam em outra tabela e você faria a ligação entre elas utilizando CodCli. Esta consulta estará trazendo repetidamente o CodCli e NomCli, enquanto que os outros campos (pela lógica) devem ser diferentes. Assim, para montar este relatório utilizando o QuickReport, voce irá precisar apenas de uma group band e uma detail. O dataset (que nesta configuração seria apenas 1) seria vinculado ao QuickRep; Na group band, voce deverá indicar o campo de quebra que neste caso será o CodCli e nela voce adiciona o CodCli e NomCli a serem impressos. Na banda detalhe voce coloca os demais campos referentes às parcelas. Qual é a lógica: - o quick irá varrer o dataset a ele associado; - a banda detail será impressa para cada item no dataset; - como adicionamos uma group band, ela será impressa a cada vez que o campo a ela associado sofrer alteração. Como ordenamos a consulta pelo nome do cliente, automaticamente o código também ficou repetido e agrupado. Assim, a group band irá observer o momento em que este campo é alterado e "se" imprime.

robinhocne, antes de comentar qualquer coisa, vou lhe perguntar: este código é o que você está usando mesmo ou você removeu alguma parte dele (sem problemas - eu só preciso saber para dar mais ou menos pitacos ;)) E uma pergunta que já precisarei de uma resposta: Observei que nas suas consultas, voce sempre usa a tabela Contas_Receber. É isto mesmo? Voce tem todas as informações na mesma tabela?

Olá robinhocne. Montar relatórios no Quick Report é mesmo muito simples. Voce apenas tem que tentar captar a ideia de como as coisas se encadeiam lá - e é muito parecido com a estrutura do relacionamento de suas tabelas. Logo, se voce montar elas corretamente, montará seu relatório também. Olhe esta figura: Voce diz que está usando um IBTable e um IBQuery e que o DataSet do relatório está ligado ao IBQuery1. Isto me leva a pensar que você vinculou todos os campos do seu relatório aos campos existentes no IBQuery1. Não é que você não possa fazer tudo em uma única consulta, mas dai você tem que ter mais atenção a como isto deverá ser desmenbrado no relatório - se via usar subdetail ou group band. A forma mais simples de você montá-lo (e entendê-lo) é seguindo a estrutura do banco de dados. Isso implicar em usar mais datasets, mas facilitará a compreensão. Assim, o dataset principal (no seu caso, aquele que trará tantos clientes quanto você deseje) é aquele ligado ao QuickRep. Quando você adiciona uma Detail band, o quickreport irá imprimí-la para cada linha deste dataset. Seguindo a estrutura de dados do banco, as tabelas relacionadas à esta utilizada no dataset principal serão aquelas a serem colocadas nos agrupamentos abaixo da detail band. No seu caso, voce teria uma consulta que estaria buscando as informações da tabela parcelas utilizando como filtro a tabela principal. Voce pode fazer isto ustilizando a ligação via DataSource (acredito que você entanda do que estou falando). Estas informações seriam mostradas no seu relatório utilizando uma banda subdetail. Dê também uma lida neste post e veja se ele lhe ajuda um pouco mais a entender o que quero dizer. Depois que você pegar a filosofia da coisa, você não vai mais ter problemas com relatório. ;)

Em teoria, esta sua tabela de parcelas seria gerada automaticamente após voce ter: valor total da duplicata, quantidade de parcelas, dia/data do primeiro vencimento. Mas é claro, isto depende de como cada um implementa seu sistema. A sua tabela de parcelas deve ter um campo que a relaciona com a duplicata. Este campo seria utilizado para voce filtrar na tabela parcelas todas as parcelas existentes para aquela duplicata. Ou ainda, se quer apenas saber quantos registros existem na tabela parcelas associada a uma determinada duplicata, então voce poderia usar uma query para a contagem (conforme mensionei): Select Count(<numparcela>) as QtdParcelas From parcelas Where <codduplicata> = :codduplicataonde os nomes entre <> são os nomes dos campos que eu não conheço. :D Dê uma olhada neste post. Ele não é exatamente sobre o seu caso, mas é pode ajudar um pouco no que tento explicar.

Achei duas opções no Google usando: "banco de dados" supermercado - 2º item da lista: é de 2010, mas aparentemente, se voce entrar em contato com o cara ele poderá lhe enviar - é este link: Banco de dados para supermercado - 5º item na lista: hospedado no 4share - é este o link: ACOUGUE E SUPERMERCADO SOUZA - BANCO DE DADOS

Seria bem estranho voce mudar o nome de um processo em execução, pois estaria caracterizando uma atividade "viral". A troco de que uma aplicação iria querer se "esconder" atrás do nome de outra?

Seguindo a filosofia da procedure acima, aparentemente voce precisaria utilizar o comando EM_GETCHARFORMAT utilizando como parâmetro a estrutura CHARFORMAT2 e no qual o campo dwMask deve conter o valor SCF_SELECTION. Eu só não posso lhe afirmar que quando houver diferentes cores em uma seleção.

Bom, não conhecemos a estrutura de dados que você está usando, então vou comentar genericamente... - se você tem uma tabela que guardas as informações da duplicata, talvez ela pudesse armazenar esta informação (quantidade de parcelas) para facilitar-lhe as coisas. - se a esta tabela voce tem relacionada uma outra tabela onde estão as informações especificamente das parcelas, então se voce simplesmente fizesse uma consulta SQL utilizando a função de agrupamento COUNT, voce conseguiria saber diretamente qual a quantidade de parcelas vinculada a uma determinada duplicata.

anabon, voce deve estar usando componentes ADO no Delphi também, não é?! (Nunca deixe de informar) No caso dos componentes ADO, o "caminho" é um pouquinho mais longo: Query_Pedido.Parameters.ParamByName('Ptelefone').AsString := txtfone.text; observações: - Voce não precisa daqueles parênteses em torno do txtfone.text; - sempre que você passar um texto como parâmetro, é boa "conduta" usar o método AsString para passar o parâmetro para a consulta porque eventualmente o parâmetro é de um tipo diferente (inteiro, float,...) e isto lhe evitará dor de cabeças, já que o próprio driver do componente irá se preocupar em fazer qualquer conversão necessária.

darkducke, voce experimentou verificar o resultado do comando ESCAPE? (no msdn) Eventualmente ele pode estar retornando estes códigos que você espera. Infelizmente é o tipo de recurso difícil de lhe ajudar já que também deveríamos ter acesso a este tipo de equipamento para experimentar as possibilides que aparecem. Boa sorte.

Ainda não tinha visto nenhuma aplicação fazendo isto (exceto as apps que vem com a impressora) e pesquisando dá para perceber que não tem muita coisa a respeito. O que exatamente você está querendo ler? Uma pista pode estar neste artigo no msdn: Bidi Printer Communication Ficam aqui dois links sobre USB: - A USB HID Component for C# - USB in a NutShell (se alguém pensar em escrever um driver para USB, precisa ler isto)

- Voce precisará adicionar a cláusula where na sua query inicial; - no form, o campo onde você digita o telefone para a consulta, não poderá ser um DBEdit - terá que ser um componente não data-aware (aqueles sem o DB...), ou seja, um TEdit ou TMaskEdit,...; - quando o número for informado, a ação ocorrerá de algum modo que você tenha em mente: quando todos os dígitos forem preenchidos, ou pressionando um botão, ou avançando ao outro campo (TAB),... - esta ação será inicializar sua consulta com o parâmetro informado. Caso não saiba, você define parametros na query ustilizando o ":". Dê uma pesquisada no forum que tem exemplos; - inicializado o parâmetro, você abre a consulta/query; - se ela não retornar qualquer registro, então voce mostra a mensagem. Eu sugiro que voce use uma mensagem do tipo "pergunta" (MessageDlg) ao invés de informar ao usuário para teclar F1 - vai simplificar as coisas; . - Se o usuário responder Sim, você coloca a tabela em mode inserção (Insert ou Append) e inicializa o campo de busca (telefone) com aquele informado no edit inicial; Os demais são data-aware (DB...) e estão vinculados ao dataset - serã automaticamente gravados no post. - se ela retornar o registro, automaticamente todos os outros DB...'s serão preenchidos. Lembrando que quando o DataSource tem a propriedade AutoEdit = true, ao digitar qualquer coisa nestes DB... o dataset será colocado em modo de edição. É mais ou menos isto Abraços

anabon, funciona sim. Mas, nunca acredite que tudo dará certo. Sua ação no OnDblClick não prevê que "seu DBGrid" esteja vazio (em algum momento ele pode estar). Se voce adicionou os fields das tabelas em design-time, dê preferência à usá-los no lugar da chamada ao método FieldByName, tipo: Table_EntregadorVeiculo.Value := Table_VeiculoCodigo.Value;

anabon, este seu código está alterando informações de 3 forms ao mesmo tempo - é para ser isto mesmo? Ou deveria alterar apenas o form do qual você chamou este form com o DBGrid que você dá o duplo clique?

E voce vai comparar o que com ele? Uma informação de outra tabela ou informado em uma tela pelo usuário?

Não exatamente...A forma a que me referi diz respeito a existência deles em design-time, ou seja, quando você dá um duplo click no componente e na janela que aparece você tem os fields ou, se está vazia, voce pode adicioná-los usando o menu de contexto (clica com o botão direito do mouse) aciona a opção "Add Fields...". Acho que o que você vai fazer é exatamente o que tem neste post.O certo registro já pode ser filtrado através da query que você vai construir. ADOQuery é o componente. Os itens a que me referi sobre ele, são suas propriedades e metodos (leia sobre OOP - programação orientada a objetos) Não. Parâmetros (Parameters) são parêmetros. Campos (Fields) são campos,... Isto que você vai implementar é tarefa de curso de informática?

Se você já programou alguma linha de código (e acredito que sim), com certeza já fez uma declaração de variável e atribuiu alguma coisa a ela. Se ainda não, aconselho a dar uma olhada em apostilas básicas, pois qualquer ajuda que alguém possa lhe dar vai exigir um mínimo de compreensão - do contrário, não haverá entendimento de ambos os lados (seu e de quem lhe responde). Fazer uma atribuição de um campo do banco de dados para uma variável é exatamente igual a qualquer outra atribuição, exceto pelo fato de que você não está estipulando uma valor fíxo (um número, um texto, ...). O seu ADOquery, depois que foi aberta a conexão com o banco, possuirá os valores do tal registro armazenado em cache e, para acessar estes valores, voce apenas tem que buscar o campo necessário - seja usando uma componente Field criado em design-time ou run-time. Voce tem que levar em conta que o tipo de dados do campo e da variável tem que ser compatíveis (inteiro/inteiro, text/string, ...) O local da declaração da variável vai depender do escopo da mesma - se local ou global - está intimamente ligado ao que você vai fazer com ela. Se seu valor for utilizado de diferentes pontos do código (procedure ou function), com certeza a declaração deverá ser global. Voce sabe como como usar os campos do componente ADOquery? Se não, voce sabe que a propriedade Fields é onde eles são armazenados? Voce adicionou os campos em design-time (no momento em que vc "desenha" os forms no Delphi)? Se sim, o acesso a eles é direto. Se não, voce sabe que ADOquery possui uma função e uma propriedade que lhe permitem acessar o conteúdo de um campo em run-time (durante a execução)?

Não! Voce não quer carregar em um Edit.Text! ;) Voce não quer porque você não pode. O componente TEdit é para ser aplicado no caso em que você tem apenas uma (01) linha de texto. O que você quer fazer é carregar múltiplas linhas e para isto você tem que usar um TMemo. A menos que você realmente precise permitir ao usuário digitar o caminho em um edit, a opção mais simples é adicionar um botão (TSpeedButton) que acione a caixa de diálogo que permitirá a seleção do arquivo desejado. O componente é o OpenDialog. Veja este exemplo: procedure TForm1.SpeedButtonOnClick(sender :TObject); begin // *** estas propriedades você pode definir em design-time - no editor de propriedades do componente OpenDialog1.Title := 'Arquivo a importar'; OpenDialog1.Filter := 'Text files (*.txt)|*.txt|All files (*.*)|*.*'; OpenDialog1.FilterIndex := 2; OpenDialog1.InitialDir := 'c:\'; //********** if OpenDialog1.Execute then // significa que foi selecionado um arquivo begin Memo1.Lines.Clear; Memo1.Lines.LoadFromFile(OpenDialog1.FileName); end; End;

Por acaso do outro "lado da linha" o aplicativo é seu? Ou se é de outro, ele espera que tipo de informação? Se for seu, voce determina o protocolo desta conversação - supondo que você possa utilizar esta via (socket) para passar outras informações que não apenas a tabela citada.

LucAlucard, o campo virtual (ou calculado como estou mais habituado a tratar) não deve ser utilizado para colunas de ordenação. Qualquer ordenação que você tente fazer sobre os dados do DBGrid tem que existir na tabela/consulta SQL - ainda que você não faça a ordenação explicitamente, o driver do banco irá providênciá-la por voce quando você acrescenta aquele ASC ou DESC. Logo, o campo tem que existir na tabela em questão. Apenas reafirmo o que o colega Jhonas lhe disse e que voce já confirmou. Se voce utiliza o DBGrid para edição, pode até ficar um pouco complicado de gerenciar, mas se este tipo de coluna não é editado no DBGrid, procure montar sua consulta SQL fazendo o lookup diretamente nela (usando o JOIN). Abraços

Sim.Assim como no Executor de Scripts (ao carregar todo o arquivo), quando voce marca/seleciona um bloco, apenas ele é executado quando você aciona o "Play" [>]. Corrigindo... DDL (Data Description Language). Nesta guia você tem o script para construção de toda a tabela, procedure, trigger,... Quando você faz uma alteração, voce não vai aplicar o script na guia DDL porque certamente obterá erro, já que o referido "elemento" já existe no seu banco de dados. Quando você conclui uma alteração e usa a opção Compilar (o raio amarelo) uma janela de validação é presentada lhe informando se há algum erro ou se está tudo Ok. Se voce observar direito, há um botão Copy Script que é o que eu utilizo antes de fechá-la. É uma tela como esta, que neste caso está apresentando uma mensagem de erro, logo não adiantaria usar a função:

Olimpio, eu não trabalho profissionalmente com programação, então vou apenas comentar como costumo realizar este processo... Se voce usa o IBExpert (IBE para incurtar) como eu, este processo de criação de novas tabelas e campos é feito utilizando ele inicialmente em sua base de dados fria (a de trabalho). Então, voce também já deve ter observado que, quando você aplica uma alteração para o banco, o IBE gera e lhe apresenta o script "gerador" da alteração. Este script eu copio e adiciono a um arquivo (usando o notepad mesmo) que será utilizado para ser aplicado à base quente (em produção) posteriormente. Neste arquivo eu coloco qualquer comentário necessário e os fragmentos de script (podem ser várias pequenas alterações) ficam separados em bloco. Para aplicar as alterações eu utilizo o IBE no cliente também. Primeiramente, voce não deve ter nenhuma conexão com o banco (ou seja, nenhum usuário acessando o mesmo). Depois executo o backup e ao nome do arquivo eu acrescento a data. Feito isto, abro o arquivo com a sequência de script e aplico um bloco de cada vez (assim, se houver qualquer problema na sua execução, fica mais fácil de acompanhar no log de erros). Ao final, eu renomeio este arquivo de script, adicionando a data à ele. Após todas as alterações aplicadas é hora de atualizar o executável que já está preparado para a "nova versão" da base, mas eu não faço a substituição do programa. Eu renomeio o existente acrescentando a data (como faço com o backup) e então copio o novo executável para o devido local. Eu dou preferência por fazer tudo o que for possível via script SQL, mas há casos em que uma alteração pode requerer a execução de um programa de conversão (migração) de dados. Nestes casos, eu sinalizo isto no arquivo de script, de forma que eu faço uma "pausa" e executo o tal programa. Espero que algum profissional possa lhe dar mais informações (idéias). De qualquer forma, voce deve sempre se preocupar em não "queimar" a base quente - faça sempre um backup antes! Da base de dados e do programa (executável e código fonte), pois assim, se algo der errado voce poderá voltar atrás com segurança. Abraços

Bom, eu não costumo usar CDS, então o que vou comentar pode não ser totalmente válido. Em termos de consulta, não deve haver qualquer problema uma implementação assim: sql := 'SELECT DISTINCT I.COD_TABELA, I.COD_ITEM LEFT JOIN TABELA_PRECO P on (P.COD_TABELA = I.COD_TABELA) FROM ITEM_TABELA_PRECO I WHERE I.COD_ITEM = :COD_ITEM'; ... with modulo do begin CDS_item_pedido_compra.close; SQL_item_pedido_compra.sql.text := sql; CDS_item_pedido_compra.Params.ParamByName('COD_ITEM').AsInteger := 2 CDS_item_pedido_compra.Open(); end;* eu troquei suas duas linhas para definição do SQL por uma só ;) Mas se voce pretende fazer atualizações nesta consulta, então poderia haver problemas sim. Estou meio enferrujado, mas para alguns componentes de acesso aos dados, existem condições em que mesmo referenciando mais que uma tabela na consulta, os dados poderiam ser atualizados - mas não posso afirmar que este será o caso. Só testando ou alguém que já o fez falar a respeito. Suponde que voce trouxesse várias colunas das "várias" tabelas envolvidas, dependendo de como seria feita a atualização dos dados (se usando componentes que não sejam DBGrid), talvez a utilização de datasets específicos para o updade pudessem ser utilizados. Eles ficariam ligados à consulta via DataSource (vinculados pelos campos chave) e viabilizariam o processo. obs: Apesar de simplicar as coisas, sempre que possível evite o uso do * na cláusula SELECT do SQL. Traga sempre apenas os campos de que precisa - assim você deixa sua consulta mais "leve" e evita o trânsito de informação desnecessária pela rede.

Não entendi direito isto... :huh: A consulta irá trazer um resultado pronto - só precisa ser parametrizada (para tirar aquele "2" fixo) Voce vai precisar explicar quem está ligada(o) a quem (tabela ou consulta sql) para eu tentar lhe ajudar. Começando por: qual a relação desta consulta com a tal tabela específica?

Até este momento, voce não tinha dito que era um aplicativo de terceiro... Neste caso não tem. Do contrário a integridade do próprio SO estaria comprometida.Na verdade, até tem. Mas para isto voce teria que "matar" o processo que "lockou" o arquivo e, provavelmente, voce não vai querer fazer isto. Se o aplicativo não fosse de terceiro, então voce poderia modificar o código daquele aplicativo para permitir a leitura e negar apenas a escrita para outros aplicativos. - quando o arquivo está bloqueado por uma chamada à CreateFile, definindo o parâmetro dwShareMode com FILE_SHARE_READ em oposição ao valor 0; - ou usando no parâmetro uStyle com OF_SHARE_DENY_WRITE em oposição à OF_SHARE_EXCLUSIVE, quando está bloqueado por uma chamada à OpenFile. Se voce ainda tiver dúuvidas sobre sobre estas questões, poderá dar uma olhada na documentação no msdn: File Management Functions Apenas destacando uma observação a respeito da Criação e Abertura de arquivos: Resumindo...Quando um arquivo é aberto em modo exclusivo, até mesmo a aplicação que o abriu não poderá abrí-lo (criar um novo handle) sem que antes o tenha fechado. Abraços * Se houver problema com o idioma inglês é só colar os links no tradutor do Google (não é perfeito, mas ajuda)