dbedits ou edits???

Olha trabalhei com Dbedits, quando utilizava paradox, hoje utiliza interbase, e utilizo só edits em meu programa, acho que assim vc controla + os dados. Utilizo um sistema de classes para fazer o trabalho p/ mim. Com certeza é bem trabalhoso + o resultado é satisfatório, porque leva vc a a decidir muita coisa em tempo de execução, e isto acaba de dando um diferencial, porque afinal de contas ligar propriedades não é tão complexo não é.
Boa Sorte se precisa de ajuda estamos ai !!

valeu obrigado!!!

:shock: :shock: :shock: :shock:

Certo, tem mais controle, mas conforme sua experiência, o q se deixa de controlar com dbEdits, a ponto de nao ser vantajoso?

Na minha opnião prefiro dbEdits, só pra telas de cadastros geralmente. Acho muito mais produtivo neste caso, e nao vejo problema nenhum, conforme meu padrao de tela de cadastro. Só nao uso onde não vejo necessidade (nos casos que trabalho com ExecSQL ao invés de Edit/Post).

Sempre defendi o uso de controles data-aware. O que muitos reclamam, talvez por falta de conhecimento, é que esses controles acabam fazendo ´coisas indesejadas´. Isso pode ser facilmente resolvido revisando seu código e usando adequada e corretamente os eventos do datasource, do dataset e também dos objetos TField associados ao dataset. Isso sem contar com o fato que é mais prático e poupa tempo em escrever código maior para controlar o que é editado.

[]s
Rubem Rocha
Manaus, AM

Acho que essa é uma questão bem particular...

Pessoalmente eu não uso data-aware... quando migrei de desktop para client/server eu pensei ´se é pra ser client/server, vou ser 100¬ client/server´... não que os data-aware não sejam, ou que sejam, mas este era meu pensamento na época...
Acabei por desenvolver uma série de técnicas q tornaram o uso de TEdits, TMaskEdits, etc, bem produtivo...
Meus ClientDataSets, por exemplo, só servem para mostrar dados no dbgrid, todas as operações com o banco são feitas 100¬ com SQL (acho até que isso pode me trazer problemas numa eventual migração para 3 camadas)...
Bem seja como for, acho que vc deve saber trabalhar das duas formas... e escolher qual a melhor de acordo com a situação...
T+

Olá

Particularmente prefiro TEdit pois seu uso não é muito mais complicado, é mais seguro e confiável. O que vc tem que fazer é codificar, e isso nem leva muito tempo.

Acho que o Custo X Benefício do TEdit é maior...mas isso eh bem particular né...

Pois eu não abro mão de controles data-aware por vários motivos:

1) Separar interface de usuário das regras de negócio;

2) Não precisar ficar escrevendo código pra copiar valor de campo de um dataset pr´um TEdit/TComboBox/etc.;

3) As regras e validações podem ser codificadas em eventos do dataset, do datasource ou dos TFields, ao invés de ficar codificando um monte de regras em eventos dos controles da tela como OnExit, OnKeyPress, OnKeyDown, OnEnter, etc., deixando a interface mais enxuta, com menos código pra dar manutenção;

4) As regras podem facilmente ser adaptadas para outro formulário, pois estão em partes separadas (data modules) dos formulários, e os controles data-aware se encarregam apenas de apresentá-los e/ou editá-los;

5) Facilita a migração do fonte do projeto para uma outra arquitetura (Ex.: Quando se trabalha em bases de dados Desktop e vai migrar o projeto pra cliente/servidor ou mesmo multicamadas);

6) Quando usado com o (agora extinto) Dicionário de Dados do BDE (Acho que poucos conhecessem esse maravilhoso artifício!), ajuda bastante no desenho rápido da tela;

E por aí vai. Se me lembrar de outros benefícios que sempre tive com controles data-aware eu posterei na lista.

[]s
Rubem Rocha
Manaus, AM

Khundalini,

Como disse creio que essa seja uma questão de decisão pessoal... vc pode enumerar quantos motivos quiser em defesa do data-aware que não vai me convencer que é melhor e eu posso enumerar os motivos pelos quais prefiro TEdits e variantes que não vou lhe convencer do contrário...
Acho que não cabe discussão quanto a isso... o colega apenas pediu nossa opinião, cabe a ele decidir qual usar...

T+

Concordo, Vinícius. Apenas ilustrei meus benefícios quanto ao uso de data-aware controls. Agora, cabe ao colega (e também ao seu nível de domínio na ferramenta) decidir o que ele irá usar.

[]s
Rubem Rocha
Manaus, AM

Ola galera..

Primeiro o dbedit ajuda muito...que vc não precisa digitar codigo..é so configura o datafield .
pegar a propriedade text e associar a query.

Ai vai muito do muito do seu conhecimento...

Espero ter ajudado...


Andrel

Compreendo... também não sei até quando meu modelo de trabalho pode perdurar, pelo pouco que andei estudando de 3 camadas, não muito... usar TEdits para Appendar ou Editar um TClientDataSet seria uma grande besteira... funciona muito bem da forma q trabalho : Query dinâmica e instruções SQL diretamente para a base envoltas em transações... pelo que vi (talvez eu esteja enganado) não seria possível passar isso direto ao servidor de aplicação...


Essa colocação é muito boa. Não usar data-aware sem dominar bem a ferramenta e a SQL, seria ´suicídio´...

T+

Olá colegas,

Não podia deixar de opinar nesse tópico, pois várias pessoas já me questionaram sobre o uso desses dois componentes.

Primeiramente o uso de DbEdit facilita muito o desenvolvimento de um aplicativo, em caso de cadastro você tem todos os campos para editar e inserindo um DBNavigator tá pronto o módulo.

O que me levou a usar o TEdit foi a necessidade de controlar a digitação e formatação dos valores, e o uso do SQL, pois é mais fácil formatar um campo no OnExit para ´100,00´ quando o usuário digita ´100´ ou ´100.00´ se for feito com DbEdit o erro ocorre na Tabela antes do Exit, o ponto decimal é decisivo.

Outro motivo foi a atualização de várias tabelas em um único formulário, muitas vezes o que temos gravado na tabela não é o que o usuário vê. Ex: você grava ´005´ e o usuário vê no TEdit ou TComboBox ´Cliente Inadimplente´

Tudo depende do tipo da aplicação, em alguns casos utilizo DBEdit por ser mais simples, em outros casos o melhor é TEdit co tratamento de erro.

Atenciosamente.

Sobre o ´100.00´ (com ponto), nao sei se entendi bem o q vc quis dizer. Mas no dbEdit, de acordo com o TField, nem é permitido o usuário digitar caracteres inválidos. Um exemplo que não vejo esse problema:

object ADODataSet1CAMPO_TESTE: TFloatField
FieldName = ´CAMPO_TESTE´
DisplayFormat = ´#,0.00´
end

Se no Windows do usuário o separador for vírgula, entao a digitação de um ponto (.) nem é permitida.


[size=9:fce3b22b75]´...você grava ´005´ e o usuário vê no TEdit...´ [/size:fce3b22b75]
Resolvi criando um TDBLookupEdit. E em alguns casos, pra consultas não pesadas, o TDBLookupComboBox já resolve muito bem.

Usando ClientDataSet nao vejo problemas e nem impossibilidades no mundo data-aware. Mas concordo com isso q vc disse, pois quando não há necessidade/vantagens, tem telas que não uso também.