Elber Carretoni

JFranco... Para aplicações em Delphi, o banco de dados FireBird é uma boa cara... é só uma sugestão...já pensou na hipótese?

Bruno, não recomendo que você na segunda tabela armazene informações da descrição do produto também...se você já apresenta esta informação armazenada, não precisa armazená-la novamente! Somente armazene na tabela 2 o código do material da tabela 1, e visualmente traga as informações da descrição do produto... Entretanto, essa informação de descrição não será armazenada na tabela 2, e sim somente atualizada sempre para que o usuário possa visualizar os dados... o simula pode achar que você armazenou novamente esta informação, quando na realidade não é o que acontece... nem sempre um dado visível em formulário precisa ser armazenado...você pode mostrar informações de forma não-acoplada (não existente em uma tabela).... deu pra entender? é só uma sugestão... abraços,

deixar o cd aberto?

é verdade...rsrs

rs...mas porque arcaico? acredito que seja a única maneira de implementar isso... O problema é que não tenho certeza que depois do "-" sempre são dois caracteres...entendeu? se for sempre dois caracteres, ficaria mais fácil... por isso que acredito que haja uma relação entre número total de caracteres do rg com número de caracteres posteriores ao "-"...é isso que eu to querendo saber... vlw mais uma vez, abração amigo...

Malj, isso funciona, mas acredito que não seja certo dizer que isso é utilizado para setar uma consulta...não é?? estive dando uma pesquisa, e descobri maneiras de como alterar a síntaxe sql da consulta...ainda não fiz os testes, mas entendo por mim que isso sim seja setar uma consulta...se eu estiver errado, por favor me corrija... Rodrigo, a dica do FindFirst do Malj está certa também...porém, o que entendi é que você quer efetuar uma consulta com o TOP 1, não necessariamente localizar o primeiro registro de uma base de dados num formulário... seja lá qual for sua dúvida, as duas maneiras funcionam... Para você acrescentar o TOP 1 direto na síntaxe SQL, abra sua consulta no Modo Design e posteriormente alterne seu modo para "Modo SQL" (Menu EXIBIR <> Modo SQL) ´ Vai aparecer um quadro branco com sua SQL...na verdade, essa SQL é a representação via código do design que você gerou da consulta...deu pra entender? aí, é só acrescentar o TOP 1 na frente do SELECT que já tá supimpa... abração...

é, complicado né? mas então Malj, somente permitir números eu sei fazer, e até mesmo era assim antes... mas eu também preciso permitir letras...e não há nenhuma máscara que permita números e letras mas não permira "." e "-", por isso que tenho que fazer isso em programação... gostaria mesmo de saber se há um padrão em relação ao RG, não referente a instituição...a instituição para qual o sistema será destinado necessita somente do tracinhu do rg...os pontos eu posso desonsiderar.... gostaria de saber se há um padrão para que também, por meio de programação, eu consiga automaticamente implementar o tracinhu... deu pra entender? vlw a atenção fera...

Salve galera, estive desenvolvendo um sistema onde qualquer um do público pode pessoalmente preencher seu cadastro via digital...enfim...todas as restrições e facilidades em entrada de caracteres devem ser implementadas, já que quando trabalhos com inclusão digital para o público o assunto se torna bem complexo... inicialmente, determinei que a entrada do RG seria só de números, nem traços nem letras nem pontos... Entretanto, me deparei com o debate da utilização de letras em RG, já que alguns possuem, e posteriormente a separação do dígito ("-"), que também é necessária... o meu RG, por exemplo, deveria ficar no sistema desta maneira: xxxxxxxx-xx. Os 'pontos', que separam as casas de milhares, posso até ignorar... Porém, o que gostaria de implementar é a permissão de digitação somente de números neste campo, e posteriormente eu trabalhasse com os valores digitados para sozinho concatenar o dígito... Mas há RG que depois do dígito apresenta dois números, como apenas um número também, sendo ainda que nem todos os rgs apresentam uma quantidade certa de caracteres...certo? Gostaria de saber se há algum padrão na determinação de máscaras para RG, ou alguma relação do tipo: "se o rg apresenta 12 caracteres, quer dizer que os dois últimos são digitos..." "se o rg apresenta x caracteres, quer dizer que os y últimos são digitos..." Enfim, estou completamente perdido e gostaria de um apoio... Caso ninguém saiba um padrão para máscara em RG's, gostaria de pedir que cada um digitasse a máscara do seu RG (sem mostrar números, apenas "x"), para que, quem sabe, possamos determinar um padrão... Abraços,

É possível sim Rodrigo... na sua consulta, coloque a função "Top 1" na sua síntaxe SQL... Abaixo segue um exemplo bem simples para encontrar o primeiro registro em uma tabela quando o nome do cliente for igual a "E*": SELECT TOP 1 Cliente.Cliente_ID, Cliente.Cliente_Nome, Cliente.Cliente_Idade FROM Cliente WHERE (((Cliente.Cliente_Nome) Like "E*")); [/codebox] Na realidade, tudo que fazemos em modo SQL, o access transforma para Modo Design, e vice versa... essa função TOP o access não converte para modo design...portanto, não sei se há possibilidades de fazê-la pelo modo Design de uma consulta... de qualquer maneira, é bem simples escrever o TOP no modo SQL... não só "Top 1", mas você pode escolher o número que quiser: "Top N" retorne os resultados ok? Abraços,

Eu, como trabalho com análise de sistemas, fica bem complexo ser contra a tal prática... Não sou formado e estou possuindo experiência apenas pela prática... Entretanto, acredito que uma análise seja indispensável na elaboração, talvez até documentação, de todos os componentes que o sistema possuirá... Atraves de uma análise é possível parar, pensar e aplicar o melhor caminho para um processamento, centralização de dados...Gerar análise de modo que seja simples para qualquer um visualizar sua análise e entender qual foi a melhor maneira de aplicar uma solução complexa e simples... Gerar análise te garante de modo fácil uma atualização no sistema para novos requisitos do cliente, fazendo com que você tenha uma idéia concreta de onde aplicar cada parte de um procedimento para que o componente funcione perfeitamente... Evita dados redundantes em tabelas e proporciona organização, que facilita posteriormente à manutenção do sistema como facilita também a implementação, propriamente dita, do mesmo... Quem tem pressa come crú...gerar uma análise acredito que em 85% dos casos seja mais eficiente... as vezes o tempo que demoramos gerando análise, acaba sendo retornado no momento da criação da aplicação, já que tudo fica mastigado e fácil... Abraços,

Patrícia, se quer somente determinar como critério SIM para este campo Sim/Não, sem efetuar contagem ou qualquer totalização, coloque somente o critério "-1"... Campos de Sim/Não se comportam com valores "-1" quando selecionados e "0" como não solucionados... Não precisa nem colocar as Aspas em torno do -1... Retorne os resultados, abraços...

Julio, dê uma olhada neste post: http://scriptbrasil.com.br/forum/index.php?showtopic=6194 abraços,

opa, vlw a dica wserial....funcionou...

rsrs...lógico, também estou correndo atrás disso e sempre quando encontro alguma solução posto no fórum... usava esta idéia bastante em delph, quando utilizada um objeto query em uma data source e indicava como fonte deste objeto um parâmetro em sql...posteriormente eu consiguia acessar dados de até um campo específico da query e trabalhar normalmente como se fosse uma outra tabela do banco de dados... senti mta falta disso quando comecei a mexer com vba! :( numa livraria vi isso de relance num livro...só não deu pra copiar a programação...rsrs mas é bem rápido e simples...vou estar fazendo os testes pelo que me lembro, você cria um objeto DAO database e outro objeto DAO QueryDef...posteriormente você seta o Data base com o seu banco de dados e depois o objeto DAO QueryDef com a SQL e depois seta alguma coisa com o banco de dados de novo... não me lembro muito bem, infelizmente... vi isso no livro "Integrando Access e Excel", da editora O'Reilly...acho que tem uma codorna na capa... se alguém tiver o livro, por favoooooooor...

É tá dando certo gente!!! Muitíssimo obrigada :lol: huauhaa...é bom demais ficar feliz por ter um problema a menos... você deve estar enganando seu patrão direitinhu agora, falando que o banco de dados gera milhões de processos e criação de consultas personalizadas por ele e tudo mais...HAHUAA...pede pra ele aumentar seu salário ô... sua idéia foi ótima...fiquei feliz só por você também ter ficado...rs abraços,

Euclides, peço desculpas pela demoro do retorno pois o tempo ultimamente está bem apertado... em contrapartida, é uma pena, mas esse problema ainda me aflige, E MUITO!rs ainda não descobri nada cara...maldito erro 2001 do inferno... se souber alguma solução, por favor, transmita-nos... abraços,

Malj, sem querer abusar, tem como explicar isso aí? explicar cada função, como a lógica do sistema vai ocorrer... se puder, ficaria muito grato... abraços,

ixi, sinto muito...

Se eu puder orientar alguma opnião em relação à sua aplicação, aceite: Entendi o que você quis fazer, porém desaprovo totalmente...o usuário pode sim definir o nome do grupo da forma como ele queira, e isso é ótimo...mas não necessariamente que você tenha que criar uma tabela com cada grupo que ele queira...você garante que amanhã o usuário não vá criar 3 milhões de grupos? e aí? A estrutura de um banco de dados nenhum usuário pode ver, e você tem então a liberdade de fazer como queira e manipular os dados para que os conteúdos apareçam da forma como quiser...dessa forma, você também pode fazer o nome dos grupos que o usuário criou aparecer para ele...se você quiser, pode até falar pra ele que cada grupo é uma tabela, quando na verdade não vai ser... com sql tudo fica mais fácil e com um banco de dados organizado é melhor ainda... o que te aconselho é que crie uma tabela de produtos e uma tabela de grupos (inclusive com o campo título do grupo que você queria que aparecesse para o usuário)... No meio dessas duas tabelas, crie uma outra que terá a função de relacionar estas duas primeiras, armazenando somente a Chave primária do Produto e a Chave primária do Grupo...dessa forma você irá criar um relacionamento muitos para muitos onde muitos grupos poderá ter muitos produtos, e vice-versa...ou seja, um produto poderá estar em vários grupos, como vários grupos poderá estar num só produto... deu pra entender? Um exemplo seria: A coca-cola está relacionada para o grupo de Bebidas...porém a coca-cola também pode estar relacionada para o grupo de Refrigerantes... no momento da manipulação da combobox no formulário, você gera uma Query que vai somente mostrar os nomes dos grupos que vem da tabela Grupos, e posteriormente você trabalha com as informações como quiser... na opnião que dei acima, a estrutura fica da seguinte maneira: Tabela_Produto Tabela_Grupo Tabela_RelacionaProdutoGrupo A tabela Produto estará relacionada de 1 para MUITOS com a tabela de RelacionaProdutoGrupo, da mesma forma que a tabela Grupo estará relacionada de 1 para MUITOS com a tabela de RelacionaProdutoGrupo...Portanto, a tabela RelacionaProdutoGrupo apresentará em si dois relacionamento de MUITOS... deu pra entender a opnião? espero que ajude! retorne os resultados... abração,

Malj, você disse que é possível sim "'autorun'ar" uma aplicação em .mdb e .mde, porém, porque o cd tem de estar aberto? A aplicação seria executada pelo CD, e todo banco de dados também mantido em CD? por isso que o cd tem de estar aberto para o banco de dados gravar novos dados? se sim, e quando o Windows do Usuário for 98? não me lembro se Windows 98 grava dados num cd aberto sem nenhum aplicativo de apoio... é possível gerar um aplicativo de instalação somente do access simulando-o como se fosse o aplicativo do sistema mdb desenvolvido?

O que o Malj falow em relação as tabelas relacionadas por chave primária é válido e está certo, porém interpretei sua dúvida de outra forma... O que entendi é que no formulário você tem vários botões de opções (radio buttons) para o usuário selecionar quais os exames do paciente...certo? porém, um paciente pode ter mais de um tipo de exame, sendo que em grupos de botões de opções só um pode estar habilitado, gerando uma alternância entre eles (se o primeiro é habilitado, o segundo é desabilitado...se o segundo é habilitado, o primeiro é desabilitado...e assim por diante)... então, em vez de botões de opção, coloque caixas de seleção ("caixa quadradinha que funciona bem parecido com botões de opção")...caixas de seleção são do tipo Boolean (Sim/Não) sendo que cada uma é individual e não necessita de nenhuma outra dependência... se essa não era realmente sua dúvida, desculpe... abraços,

Olá Elber Quando construi o formulário coloquei em Bairro as seguintes opções de escolha (Meier, Lins, Outros) é uma lista que não pode ser expandida e nem mudada. No relatório gostaria de saber quantas pessoas moram no Meier. Como é uma função textp tenho que utilizar Contar. Att Patrícia :rolleyes: Patrícia, vê se eu entendi: você quer gerar um relatório único para o bairro, e não gerar um relatório que mostre todos os bairros (relatório agrupado) e as respectivas quantidades de registros? Ou seja, em vez de gerar um relatório com "Meier: 20 / Lins: 40" (todos bairros num relatório só - relatório agrupado), você quer selecionar o bairro numa caixa de combinação e determinar o relatório "Bairro_Caixa_Combinação: 20" (relatório para bairro único)... deu pra entender o que eu tentei entender?rs

Patrícia, acredito que, com as descrições do seu post, você esteja criando um relatório agrupado por bairros...certo? Se sim, na seção de agrupamento por bairro, coloque apenas a expressão "=Contar(*)" ! Dessa forma, o access irá definir a quantia de registros por cada grupo... Caso você utilize da mesma expressão porém fora da seção de agrupamento, o access irá contar o total de registros independente do bairro... Deu pra entender? Faça os testes e retorne os resultados... Beijo,

no critério, utilize desta síntaxe: Como "*xx*" Neste caso, a filtragem será efetuada para todos os registros que estiverem com a combinação xx no meio de uma string... Como, em SQL o access irá transformar para "Like", que é um critério de comparação semelhante, não completamente "="... deu pra entender? retorne os resultados... abraços,

Não te aconselho não Br... consultas em SQL sempre dão problemas quando se faz uniões em tabelas diferentes que envolvem os mesmos nomes de campo...semana passada mesmo me deparei com uma consulta em sql que dizia que, em seu parâmetro, dois campos com o mesmo nome estavam sendo vinculados por tabelas diferentes e a consulta não poderia ser realizada, mesmo com os Alias diferentes e devidos para cada tabela... aconselho que você adote um padrão de nomeclatura, tanto para objetos em formulários, como para tabelas e campo de tabelas.... costumo usar assim em nome de campos: NomeTabela_NomeCampo tblCliente_ID tblVenda_ID_tblCliente além do mais, utilize nomes obvios e sem muita abreviação...adote um padrão para utilizar de plural e singular (tabela Cliente ou tabela Clientes?)...gerar consultas com várias tabelas que apresentam nomes totalmente complexos e desorganizados é estar num inferno...organização em nomeclaturas vale a pena e tempo! abraços,