Micheus

Acho que está faltando apenas um Inifile.Free, dê uma conferida. Try Inifile := TIniFile.Create('C:\Sysbib\Dados\ConfDB.ini'); Inifile.WriteString('DATABASE',URL,'C:\Sysbib\Dados\SYSBIB_DB.GDB'); Inifile.WriteString('DATABASE','SYSDBA',USR); Inifile.WriteString('DATABASE','masterkey',PWS); Inifile.Free; // ***** Except ShowMessage('Ocorreu um erro!!!'); end;

Vivendo&Aprendendo, com o intúito de resolver as questões referentes aos parâmetros e a função correta para o banco, de modo a que você obtivesse um resultado, uma questão mais importante passou despercebida: A consulta SQL funciona como esperado? E a resposta é não! Após responder ao post do JPedro (refletindo sobre isso), acabei por perceber que a consulta funciona parcialmente. Vejamos: 1) Período dentro do mesmo mês. Ex. 10/03 - 28/03 2) Período que envolvam mais que um mês, onde o período inicial começa em 01/.. até um mês que termine com 31/..; Desde que dentro do mesmo ano. WHERE MONTH(DATANASC) between :MesI and :MesF AND DAY(DATANASC) between :DiaI and :DiaF Observe que se solicitamos um período entre 10/01 até 28/02, utilizando a query como está: filtrando aniversariantes nos meses de Jan e Fev e com o dia entre 10 e 28; Logo, ficaremos sem os alunos com aniversário entre os dias 01 a 09 de Jan e Fev, bem como os de 29 a 31 de Jan. Outro, problema também ocorre se o período começar com um mês inicial maior que o final. Por exemplo, num período entre 01/12 a 31/01 (aniversariantes do final e início do próximo ano), substituindo os parâmetros na consulta:SELECT Alunos.* FROM Alunos WHERE MONTH(DATANASC) between 12 and 01 AND DAY(DATANASC) between 01 and 31; teremos como resultado todos os alunos, porque no primeiro between, é como se tivesse sido digitado 01 and 12, ou seja todos os meses. Podemos ver, que se a query necessitasse considerar apenas o mês de aniversário, ainda assim, ela não estaria retornando resultados corretos. A sugestão (se tiverem outra mais simples postem, por favor) seria mudar a query dinamicamente (como já é feita), de modo que quando o mês final for maior que o inicial, sejam realizados dois filtros: do mês inicial até o mês 12 e do mês 01 até o mês final. Isto resolveria a questão do filtro por meses. Mas, em nosso caso temos ainda que levar em conta o dia, então, minha sugestão é "concatenar" dia e mês num cálculo. Multiplicaríamos o mês por 100, de mos que somando o dia, obteríamos números crescentes e de fácil comparação. Por ex.: 10/01 até 28/02, teríamos como comparação o cálculo das datas de nascimento com os valores 110 a 228, isto garanteria qualquer resultado intermediário, como 31/01 que seria 131.var DtInicio, DtFim :TDateTime; Inicio, Fim :Integer; begin DtInicio := StrToDate(EdtInicial.text) DtFim := StrToDate(EdtFinal.text) Inicio := MonthOf(DtInicio) *100 +DayOf(DtInicio); Fim := MonthOf(DtFim) *100 +DayOf(DtFim); with DmDados.Alunos do begin Close; SQL.Clear; SQL.Add('SELECT * '); SQL.Add('FROM Alunos '); if MonthOf(DtFim) < MonthOf(DtInicio) then begin SQL.Add('WHERE (Month(DATANASC)*100+Day(DATANASC)) BETWEEN :Inicio AND 1231'); SQL.Add(' OR (Month(DATANASC)*100+Day(DATANASC)) BETWEEN 101 AND :Fim'); end else SQL.Add('WHERE (Month(DATANASC)*100+Day(DATANASC)) between :Inicio and :Fim'); SQL.Add('ORDER BY DATANASC'); Parameters.ParamByName('Inicio').DataType := ftInteger; Parameters.ParamByName('Inicio').Value := Inicio; Parameters.ParamByName('Fim').DataType := ftInteger; Parameters.ParamByName('Fim').Value := Fim; Open; end; end; Se não esqueci de mais alguma coisa... Abraços

Lafey, dá uma espiada deste post em diante. Talvez lhe dê uma idéia de como resolver seu problema. Abraços

Não.Acesse este link e siga as instruções para istalação com o QR4. Abraços

Jsjsoft, o problema é exatamente o mesmo que você já sanou em outro post. Para evitar que a cada diferente projeto que você reabra (projetos antigos, que estavam no outro computador) dê um erro semelhante, você terá que reinstalar todos os componentes que por ventura você tenha utilizado. Abraços

Primeiramente, porque a idéia é procurar os aniversariantes baseado no dia e mês (um período é informado) em que o aluno faz o aniversário, e não, simplesmente o mês. E se desejar saber quem faz aniversário esta semana apenas? Segundo, porque sendo informado um período (é o que o colega Vivendo&Aprendendo propôs inicialmente), ainda que utilizando apenas o mês na consulta, você teria que retirá-lo dos seus Edit1.text e Edit2.text - não daria para simplesmente concatená-los. Terceiro, acho que você perdeu esta parte do post. As sugestões iniciais indicavam o uso de EXTRACT, entretanto o MSAccess não tem esta função. É possível observar que uma mesma consulta SQL não pode ser utilizada em todos os bancos. Então, como estava com um tempinho, levantei justamente a questão da manipulação de datas por diversos bancos. Esta é uma questão em que sempre ressalto a validade da utilização de parâmetros, e não a concatenação, nas query's realizadas. Deste modo, no caso da necessidade de comparar/tratar datas, não há necessidade de qualquer preocupação já que ao passar o parâmetro, os driver's que fazem o intermédio entre o banco e a aplicação resolvem estes problemas para nós. Caso alguém tenha alguma correção, por favor faça. Como evidentemente, não conheço todos os bancos citados, coloquei os link's de referência ao lado. Espero que seja útil a alguém. SQLServer - Suporta as funções Day, Month, Year, ... .Não tem a função EXTRACT, porém, a mesma funcionalidade é obtida através da função DatePart (link) MSAccess - Sendo, também, da Micro$oft, vale o que foi escrito para SQLServer (link) MySQL - suporta as funções EXTRACT e Day, Month, Year, ... (link) - Aceita aspas simples ou dupla como delimitador das constantes alfa-numéricas. Como delimitador, o MySQL utiliza o acento grave (crase) - a data, quando concatenada como uma constante, deve estar no formato yyyy-mm-dd. Experimente concater o conteúdo de um edit com a data no formato que foi digitado (dd/mm/yyyy). InterBase/FireBird - até onde sei e apurei, suportam apenas EXTRACT. O uso de funções como Day, Month, Year, ... dependem da instalação de UDF's; - A partir da versão 6, utilizando o Dialect 3 constantes alfa-numéricas devem ser delimitadas por aspas simples. As aspas duplas são utilizadas como delimitador de um identificados (nome de tabela, campo) (link) PostGre - Pelo que levantei, tem apenas EXTRACT (link) Oracle - Pelo que levantei, tem apenas EXTRACT (link - ver Datetime Functions) SyBase Entre as funções para manipulação date/time não há EXTRACT link Paradox - Só dá para utilizar EXTRACT. Inclusive, percebí algo "interessante" com ele. Se contatenar-mos a data como string, poderá ocorrer uma interpretação dúbia. No exemplo abaixo, supondo a contatenação de uma data no formato dd/mm/yyyy (normalmente digitamos assim), seria esperado um resultado positivo, certo?! (observe a cláusula where)select T.*, extract(month from cast('01/02/2006' as date)) mês from teste T where extract(month from cast('01/02/2006' as date)) = 2 Entretanto, nesta situação, o paradox não irá retornar linha alguma, porque ele estará utilizando o formato mm/dd/yyyy. Agora, experimente colocar a consulta desta forma:select T.*, extract(month from cast('20/02/2006' as date)) mês from teste T where extract(month from cast('20/02/2006' as date)) = 2A princípio, eu alterei apenas o dia de 01 para 20, mas pensando no fato de na consulta anterior o paradox ter interpretado este campo como mês, me parece que deveria ocorrer um erro, não?! Pois então, não ocorre e, neste caso, ele assume a formatação esperada inicialmente dd-mm-yyyy. Isto definitivamente não parece bom!!! (eu testei com o Paradox 7 no Data Base Desktop) "Mas que confusão ..." Confusão? Há meios de minimizar esta "confusão", mas pelo tanto que escrevo é melhor deixar para outra oportunidade. ;) Abraços

Pedro, Quando você sai do form de impostos você não estaria fechando o dataset impostos, se ele for o mesmo ligado a propriedade ListSource do DbLookUpComboBox?

Este é um componente da RXLIB. você provavelmente não instalou ele na sua nova máquina.Caso não o tenha, segue o link para download: http://www.delphibr.com.br/download/delphi/rxlib_275d7.zip Abraços

Testei o código para utilitazação do scroll e está funcionando corretamente com o DBGrid, ou seja, o foco da linha se modifica corretamente.Acredito que seja uma questão de atualizar seus edit's adequadamente. A dica funcionará 100% se você estiver utilizando componentes dataware (os TDB... da paleta Data Controls), isto porque são linkados ao dadaset e refletem qualquer posicionamento no mesmo. Assim, a sugestão que tenho é que você simule esta situação utilizando um DataSource em seu form, que apontará para o mesmo dataset que DBGrid, de tal modo que através do seu evento OnDataChange você aciona o procedimento que atualiza os edit's. Sugestão: 1) adicione um TDataSource ao form frmVLENTR, vamos chamá-lo de DSSelLocal; 2) configure a propriedade DataSet com o mesmo valor utilizado nesta propriedade do DataSource ligado ao DBGrid. Voce pode fazer isso em design-time ou em run-time adicionando no evento OnActivate a linha: DSSelLocal.DataSet := DBGrid1.DataSource.DataSet; 3) no evento OnDataChange do DSSelLocal você adiciona a chamada ao seu procedimento EdtRecebeDados; procedure TfrmVLENTR.DSSelLocalDataChange(Sender: TObject; Field: TField); begin EdtRecebeDados(Sender); end; Com isto, qualquer movimentação no DBGrid se refletirá nos edit's. Caso o dataset associado ao seu DBGrid1 esteja em um datamodule, talvez você tenha que testar se ele está alocado (if Assigned(datamodule) then) antes de chamar EdtRecebeDados. Comentários: Se EdtRecebeDados é um procedimento apenas para inicializar os dados dos edit's: - não há necessidade de definir o parâmtro Sender, principalmente porque não é utilizado para nada; - se IBQSelVlentrega é aberto na atualização dos edit's, aparentemente ele retorna algum tipo de totalização para a linha selecionada, então ele não deveria ser fechado antes da abertura? Ou talvez ele seja aberto apeanas uma vez, e então, provavelmente devesse ser aberto em outro ponto que não a cada movimentação no grid. Quando você acessa os componentes dentro de seu próprio form ou datamódule, não há necessidade de referenciá-lo agregando o nome do mesmo. Por ex., a linha em EdtRecebeDados: frmVLENTR.EdtCodVlEntr.Text:=dbgrid1.DataSource.DataSet.Fields[0].AsString; poderia ficar simplesmente: EdtCodVlEntr.Text:=dbgrid1.DataSource.DataSet.Fields[0].AsString; Voce não mostrou onde atribui um valor a KeyValue, mas se for utilizar o procedimento acima citado, provavelmente funcionará. Abraços

É um erro de run-time ou de compilaçao? Qual a mensagem original no Delphi?

regulando o espaçamento vertical você tem:- 1/8 de polegadas ou 8 lpi(linhas por polegada) - 1/6 de polegadas ou 6 lpi(linhas por polegada) já para o horizontal, usualmente: - 10 cpi (caracteres por polegada) - default - 12 cpi - 15 cpi você deve enviar os caracteres de controle da impressora, adequado ao que você quizer setar. Abraços

Fazendo a consulta dentro do MSAccess (MSOffice 2000), dá para ver que é coisa do access mesmo. Se você não definir os parâmetros explicitamente ele trata a informação da forma não desejada (tenho uma vaga idéia do motivo em função dos testes). parameters MesI INTEGER, MesF INTEGER; SELECT *, DAY(DATANASC)as Dia, MONTH(DATANASC) as mês FROM Alunos WHERE MONTH(DATANASC) between MesI and MesF AND DAY(DATANASC) between 1 and 31 ORDER BY Codigo Assim, acabou não sendo difícil observar que o problema residia neste fato. Então, alterando um pouco o procedimento, foi possível obter o resultado correto, ou seja, defini o tipo de cada parâmetro antes de atribuir um valor a ele:... Parameters.ParamByName('MesI').DataType := ftInteger; Parameters.ParamByName('MesI').Value := MonthOf(StrToDate(EdtInicial.text)); Parameters.ParamByName('MesF').DataType := ftInteger; Parameters.ParamByName('MesF').Value := MonthOf(StrToDate(EdtFinal.text)); Parameters.ParamByName('DiaI').DataType := ftInteger; Parameters.ParamByName('DiaI').Value := DayOf(StrToDate(EdtInicial.text)); Parameters.ParamByName('DiaF').DataType := ftInteger; Parameters.ParamByName('DiaF').Value := DayOf(StrToDate(EdtFinal.text)); ... Isto acaba sendo necessário simplesmente porque você está montando a consulta em tempo de execução. Se você utilizar umcomponente TADOQuery especificamente para esta consulta (não precisará mudá-lo no código) poderá adicionar o select, em design-time, na propriedade SQL e declarar o tipo dos parâmetros através da edição propriedade Parameters do componente. Em função do exposto no seu outro post, acredito que seja a melhor opção. Abraços

Vivendo&Aprendendo, vou seguir deste post para tentar exclarecer(também) aos colegas que acompanham, de onde vinha o problema com a referida mensagem de erro. Pode servir de alerta para quem utiliza método parecido. Primeiramente, convém salientar que seu datamodule tem um componente TADOQuery com o nome Alunos com a propriedade SQL(em design-time) definida como: Select * From Alunos Sendo que também foram adicionados os campos a este componente, resultando em 31 campos (existentes nesta tabela, resultado do select), dentre eles está o campo "Codigo". A propriedade FieldDefList nos dataset's mantém uma lista de campos (TField) adicionados em design-time ou em run-time, quando o dataset é aberto. Se campos foram adicionados em design-time, ao abrir o dataset, uma verificação é realizada. Justamente aqui está o problema. Nesta consulta que você faz em run-time (grifado acima), alterando a propriedade SQL, passando a relacionar as tabelas Alunos e Histórico, você busca todos os campos de ambas as tabelas, que tem como resultado 45 campos. Não haveria problema algum se não houvessem campos com o mesmo nome em ambas as tabelas. Ocorre que, ao abrir a consulta, uma nova lista de campos (propriedade FieldDefList) é gerada e uma chamada ao método BindFields(True) para realização uma "consistência" entre os campos obtidos com a consulta (lista FieldDefList) e os adidionados em design-time (lista Fields). Como há campos com o mesmo nome em ambas tabelas, a lista FieldDefList possui os campos com os nomes 'Alunos.Codigo' e 'Historico.Codigo', entretando a lista Fields possui um único campo com o nome 'Codigo', obtido pelo select simples (apenas tabela Alunos, lembram) e a não localização do mesmo na lista FieldDefList resulta na mensagem de erro citada. A melhor maneira de resolver este problema, então, seria adicionar na cláusula SELECT os campos um-a-um, utilizando um alias, para facilitar, e "renomeando" os campos duplicados. Por ex.:SELECT H.CodAluno, A.Nome, A.DataNasc, H.Codigo as CodHistorico, H.Disciplina FROM Alunos A, Historico H WHERE A.Codigo = H.CodAlunoNote que utilizando CodAluno do histórico já estará obtendo o Codigo do Aluno, além de deixar claro de que "código" se trata. Do mesmo modo, "renomear" Codigo em Histórico para CodHistorico, gera o mesmo efeito e evita qualquer confusão. * Sobre o uso do AS, ele é necessário no caso do MSAccess Convém utilizar uma consulta TADOQuery para cada situação, ou seja, uma para a pesquisa dos alunos aniversariantes e outra para o histórico dos alunos. Deste modo você pode adicionar os select's nas respectivas propriedades SQL, configurar a propriedade parameters e adicionar os campos aos componentes em design-time. Dica conveniente para resolver problema com seu outro post também. Espero ter sido claro. Infelizmente não consegui ser muito sussinto e se houver alguma "abobrinha" na minha explanação, queiram-me corrigir. Abraços

Se você estivesse manipulando o evento OnNeedData (responsável pelo avanço de linha no registro do dataset quando você controla a impressão - não quickreport), eventialmente você poderia estar utilizando o método TQuickRep.NewPage para forçar quebra de uma nova página.

Por isso que insisti para que você testasse com meu exemplo. Como estava imaginando, deve haver alguma particularidade nas suas telas.Talvez seja a forma da conexão - já conferiu os parâmetros, não estaria apontando para outro database, que você possa ter utilizado anteriormente e que ainda não tenha o campo com este nome? Outra situação em que este tipo de erro pode ocorrer é quando você tem um campo associado a um componente dataware (tipo TDBEdit) e por algum motivo troca o datasource de onde deveria estar vindo o field. Teria alguma situação como esta? Se não conseguir achar o problema, e quizer, me envie apenas o datamodule que você está utilizando (tem que ter ao menos a cópia do componente de conexão dentro dele) e a tela da consulta que eu testo com aquela base de teste que você me enviou. Abraços

Vivendo&Aprendendo, por acaso você testou o programa demo que eu fiz, utilizando a sua tabela quente? Faça isso e diga se com ele, as consultas estão funcionando, por favor. Compile-o e coloque seu database na pasta em que você o tiver colocado - há um botão para executar cada uma das duas dúvidas que você postou aqui no forum. Abraços

rodrigo biagioli, você estaria manipulando algum evento de teclado. Tipo, teria habilitado o KeyPreview e intereceptando OnKeyPress/OnKeyDown ou OnKeyUp?

Alisson, pelas técnicas de normalização de banco de dados você provavelmente tem algo assim, certo?!: +---------+ +------------+ +----------+ | Item | | Autor_Item | | Autor | +---------+ +------------+ +----------+ |Cod_Item |1 N|Cod_Item |N 1|Cod_Autor | |Dsc_Item |----|Cod_Autor |----|Dsc_Autor | |... | |... | |... | +---------+ +------------+ +----------+ O problema pode não estar necessariamente com o Rave. Se há a possibilidade de haver "+ d um autor relacionado ao mesmo ítem", significa que você terá o par Cod_Item|Cod_Autor repetidos na tabela Autor_Item. Deste modo para que apareça apenas uma ocorrência do mesmo, você poderá utilizar uma query onde agrupará os dados por estes campos. Assim, apenas será gerada uma linha para cada par como resultado de sua consulta. Seria algo mais ou menos assim:SELECT I.Dsc_Item, A.Dsc_Autor FROM Autor_Item AI, Item I, Autor A WHERE AI.Cod_Item = I.Cod_Item AND AI.Cod_Autor = A.Cod_Autor GROUP BY I.Dsc_Item, A.Dsc_Autor Abraços

É possível fazer isto utilizando a classe TQRPHandler, definida na unit QRBonus (versão 2 do quickreport) ou na unit QRExtra (versão 3 do quickreport).Ex. procedure TForm1.Button2Click(Sender: TObject); begin with TQRPHandler.Create do try Filename := 'c:\temp\relatorio.QRP'; Preview; // se for para imprimir diretamente utilize Print nesta linha finally Free; end; end; Para quem se interessar em conhecer algumas das limitações/recursos do QuickReport, aqui está o link para o arquivo de Perguntas e Respostas (QuickReportFAQ.doc). Abraços

Vivendo&Aprendendo, Confirme o exemplo que lhe passei por e-mail e veja se com sua base quente vai funcionar. Não obtive qualquer erro utilizando aquela consulta em seu post inicial. Como você não mensionou que componentes utiliza para fazer o acesso, eu utilizei TADOConnection e TADOQuery, com parâmetros padão. A propriedade ConnectionString do TADOConnection ficou Provider=Microsoft.Jet.OLEDB.4.0;Data Source=U:\Micheus\Delphi 7\Projetos\Teste Alexandre\dados.mdb;Persist Security Info=False. Informe mais detalhes sobre componentes utilizados, modo de acesso, já que existem outros. Só assim, quem sabe, consigamos gerar seu problema. Abraços.

Não deu o quê - como?Como questionou o Kikonanet, retorna algum erro? Erro de execução ou compilação? Abriu a consulta normalmente, mas não trouxe registros? Confirme o exemplo que lhe passei por e-mail e veja se com sua base quente vai funcionar, porque com a de teste que você me enviou eu utilizei exatamente a consulta acima e ficou legal - exceto pelo fato que só havia 01 registro em 15 que continha o campo DATANASC preenchido e então preenchi mais alguns. :huh: Aproveito para sugerir que você utilize o TDateTimePicker (paleta Win32) no lugar dos TEdit's para a entrada das datas. Abraços

Aghata, seguindo a sugestão dos colegas Erso e Churc, você deve opnar por ler do arquivo ou do clipboard:{ // lê do arquivo em disco para o DBImage if OpenDialog1.Execute then DBImage1.Picture.LoadFromFile(OpenDialog1.filename); Table1.Post; } ou{ // lê do clipboard para o DBImage DBImage1.Picture.Assign(ClipBoard); Table1.Post; }

Alisson, você pode incluir quantos campos quizer, entretando isso aumenta o risco de gerar linhas duplicadas para os itens principais que você pretende mostrar - você deve saber que campos podem gerar tal "problema". Apenas fazendo a consulta completa você terá uma noção exata de como ficará o resultado final. acho que não vai dar porque eu não utilizo Rave. Espero que outro colega possa lhe ajudar neste sentido. Abraços

Erso, convém lembrar que no desenvolvimento dos programas, este é um importante recurso para detectar/sanar erros, já que a execução será interrompida e o cursor posicionado na linha em que ocorre o erro. Desabilitar esta opção implica em ter as mensagens de erro na aplicação, o que para alguns significa mais dificuldade em encontrar a origem do problema. Abraços

rodrigo biagioli, não precisa gritar (caixa alta).Como é que iria saber se este campo você digitava utilizando um Memo ou similar ou se você contatenava um texto e gravava nele (nestes casos, tem gente que inclui apenas o #13 ou #10). Abraços