MODELAGEM DOS DADOS

USUARIO.EXCLUIDOS 29/12/2004 10:12:42
#57556 Resposta escolhida

Vamulá!

A quantidade de campos que uma tabela PODE possuir varia em função do engine de dados adotado.

No caso do MS-Access, a quatidade de campos de uma tabela pode chegar á 255 (0 á 254), sendo que nenhuma consulta armazenada poderá representar mais do que 250 campos (versão 2002/2003). Vamos ampliar mais esses dados?

As especificações atuais para o engine do MS-Access, usado pelo VB, são:

- Tamanho do arquivo de dados: Até 2 Gbytes menos o espaço ocupado pelos objetos de sistema;
- Campos por tabela: 255;
- Campos por consulta armazenada: 250;
- Tamanho máximo por tabela: 2 Gbytes menos o espaço ocupado pelos objetos de sistema, ou seja, uma tabela pode ocupar toda a base de dados;
- Caracteres em um campo do tipo texto: Até 255;
- Caracteres em um campo memo:: 65535 (restrito apenas pela entrada de dados manual, uma vez que os objetos de texto do VB têm esse limite) ou até 1 Gbyte (quando a alimentação do campo é codificada);
- Caracteres máximos em uma célula de consulta (ou grade): 1024;
- Número máximo de caracteres em um campo para entrada de dados (form): 65535;
- Número máximo de sub-consultas aninhadas: 7
- Número de bases diferentes (ou áreas de trabalho concomitantes) abertas: 255;
E o principal, para o seu caso, deve ser esse último limite do MS-Access:
- Capacidade máxima de caracteres por registro: 2000 (excluindo campos dos tipos Memo e OLE);

Se você estivesse utilizando um SQL Server ou ainda um MSDE, só para exemplificar, o número máximo de campos por tabela subiria para 1024, nas versões 7 e posteriores.

Mas esses são os limite do engine, ou seja, representam uma quantidade hipotética de campos e quantidades de caracteres como limitação de trabalho. Se fosse esse o caso, você estaria com tudo perfeito. Só olhar esses limites indica que você poderia trabalhar com até 510GBytes em dados intercalados, sendo que para cada área aberta há a RECOMENDAÇÃO de até 160 usuários, portanto, até 40800 usuários "on-line" (ufa!).

Já trabalhei com bases de dados MS-Access com mais de 2GBytes e conheço bem esses limites do engine, seus problemas de tráfego de rede, suas falhas de segurança e até alguns macetes geniais, capazes de tornar o MS-Access bastante interessante, estável e seguro, graças ao dia-á-dia de três anos na segunda maior empresa de transportes marítimos do mundo. Já discuti e "troquei figurinhas" por muito tempo com o pessoal da Microsoft, apenas para manter as aplicações "afinadas" e funcionando em tempo real com bases sincronizadas em 6 estados diferentes (SP, RJ, RS, SC, ES e PE), pois não se podia perder tempo na captação de fretes.

Observe que a questão não reside, porém, na capacidade máxima de armazenamento de um engine qualquer, nem em seus limites de uso, mas sim na maneira como esse armazenamento é administrado.

Vamos tentar um exemplo para ilustrar. Primeiramente, vamos entender como é administrado o espaço de trabalho, ok? Suponha que você tenha uma tabela com apenas três campos, dois deles do tipo Text e um do tipo Memo. Os campos do tipo memo podem armazenar, por registro, até 1GByte em informação, como vimos. Mas ao criar um campo memo, sua primeira idéia é a de possibilitar a armazenagem de pequenos textos, entrados não por formulário mas por selecionamento de arquivos pelo usuário, com até 150K. Com o uso, a média dos campos memo continua dentro das espectativas e isso não acarreta nenhum problema. Em dado instante, um usuário resolve inserir texto suficiente para ocupar toda a capacidade do campo. O que acontecerá?
1 - O engine realizará cálculos para determinar a média de tamanho por registro, contabilizando essa última entrada.
2 - O espaço de trabalho tentará alocar recursos para que a média por registro esteja disponível por estação de trabalho, tornando o sistema um pouco mais lento.
3 - Em controles multi-registro, como os DataControl, os recursos á serem alocados serão multiplicados pelo default de registros em carga, que é de 50.
4 - Em algumas telas, o sistema cliente irá travar.
5 - O travamento do sistema em alguns pontos da rede poderá acarretar novas chamadas ao serviço de dados, empilhando mais processos na rede e possibilitando a ocorrência de crashes e consequentemente a "quebra" da base de dados (quando isso ocorre, a mensagem de erro ao tentar acessar a base de dados pode variar entre "Formato de Dados Não Reconhecido", "Formato Inválido da Base de Dados", "Base de Dados Corrompida" etc).

Ora, o erro apresentado acima não chegou nem perto de infringir os limites do engine. Ocorreu apenas por um "deslize" na administração dos dados.

Então, de princípio, sabemos que as sessões ativas e as áreas de trabalho são efetivamente ambientes preparados pelo engine para tratamento dos dados, não sendo de forma alguma estáticas, como acontecia no DOS. Uma área de trabalho MS-Access (não é apenas o Workspace do DAO, mas também a sessão ativa em ADO para engine do Jet) é dinà¢mica, expandindo-se e retraindo-se á medida em que a própria base de dados evolui.

No caso específico do MS-Access, essa área de trabalho é um tanto diferente das dos demais engines comerciais de dados, por lidar SEMPRE com volumes de informação maiores. Você, neste ponto, deve estar se perguntando: "Poxa, se o MS-Access é menos robusto do que o Oracle, por exemplo, como sua área de trabalho lida com maior volume de informação? Não é lógico..."

Bem, esse é o segundo ponto. O MS-Access transita TODO o conjunto de dados, sempre, não apenas os subconjuntos representados por uma consulta solicitada. Isso quer dizer (principalmente se ainda está adotando o DAO) que ao abrir a base, a aplicação-cliente estará carregando localmente todos os dados, sempre que abrir um recordset, para realizar as filtragens e seleções na própria estação. Tanto a área de trabalho do MS-Access é mais pesada como também o fluxo de dados na rede, se comparados á outros engines. Não se desespere, o ADO ajuda MUITO neste ponto.

Então temos agora mais um ponto, que foi aquele levantado por nós em seu post anterior. é o relacionado a normatização de dados.

Não é (nem deve ser) LEI que uma tabela tenha no máximo 15 campos. Quando se fala em quantidade média de campos, isto leva em conta apenas estruturas de dados coerentemente normatizadas, onde se prima por uma quantidade de campos menor em nome de três fatores: Tamanho final do conjunto de dados, desempenho e segurança da informação.

Como eu disse, não tenho a ilusão de que você respire a normatização da noite para o dia, isso seria inviável para a maioria de nós. Mas com o tempo, acredito ainda que irá perceber as vantagens dessa metodologia, que facilita a manutenção, a criação de objetos de negócio, de stored procedures, de views, de controles de usuário especialistas etc.

Ainda assim, vamos dar uma passada rápida no que você, hoje, considera como ideal para o conjunto de informações sobre vendedores? Isso pode lhe dar uma idéia mais próxima do que eu tento lhe passar. Hoje você tem:

Arquivo: vendedores.mdb
Tabela : vendedores
àndices: código, nome, cpf

Código 10
Nome 60
RG 20
CPF 20
Endereço 40
Número 10
Complemento 40
Bairro 40
Município 40
UF 2
CEP 10
E-Mail 60
Home-Page 60
Fone 20
Celular 20
Fax 20
Contato 40
Data de cadastro 10
Data de nascimento 10
Banco (Nome.) 40
Banco (Número.) 10
Agência (Nome.) 40
Agência (Número.) 10
Número da conta 20
Comissão a vista 10
Comissão a prazo 10
Comissão após Recebimento 10
Lembrete 250

Não se "esquente" com as críticas á seguir, não o faço de forma pejorativa.
1 - Caso o vendedor apresente mais de um conjunto de informações relacionadas aos contatos e/ou endereços, a estrutura acima exige que ele seja cadastrado novamente, com as informações complementares.
2 - O campo Banco será repetido indefinidas vezes, ocupando um espaço precioso da base de dados, sendo que só precisaria existir uma única vez e ser referenciado por um inteiro longo, de tamanho bem menor.
3 - Para "deixar por aqui" (não quero entrar em méritos como gravar ou não máscaras de texto etc), os dados financeiros de cada vendedor estão juntos na mesma tabela, de forma que, sob o ponto de vista de segurança da informação, é muito mais simples "roubar" tais dados do que se eles estivessem em tabelas vinculadas.

Aí você pode pensar: "Oras, se é assim, como é que eu poderia fazer essa estrutura, então???" Mãos á obra!

TB_VENDEDORES
===============
ID_VENDEDOR INTEIRO LONGO AUTONUMERAÇÃO
NOME TEXTO 60
IDENTIDADE TEXTO 20
CPFJ TEXTO 20
DT_CADASTRO DATE/TIME
DT_NASCIMENTO DATE/TIME

TB_ENDERECOS
=============
ID_ENDERECO INTEIRO LONGO AUTONUMERAÇÃO
ID_VENDEDOR INTEIRO LONGO
ID_TIPO_LOGR INTEIRO LONGO (*) - VIDE ABAIXO
LOGRADOURO TEXTO 40
NUMERO TEXTO 10
COMPLEMENTO TEXTO 40
CEP TEXTO 10
BAIRRO TEXTO 40
CIDADE TEXTO 40
UF TEXTO 02
FONE TEXTO 20
CELULAR TEXTO 20
FAX TEXTO 20
CONTATO TEXTO 40

TB_ELETRONICO
==============
ID_ENDEREÇO INTEIRO LONGO AUTONUMERAÇÃO
ID_VENDEDOR INTEIRO LONGO
ENDERECO TEXTO 60
ID_TIPO INTEIRO LONGO (*) - VIDE ABAIXO

TB_PARAMETROS_FIN
===================
ID_PARAMETRO INTEIRO LONGO AUTONUMERAÇÃO
ID_VENDEDOR INTEIRO LONGO
ID_BANCO INTEIRO LONGO
AGENCIA_NOME TEXTO 40
AGENCIA_NUMERO TEXTO 10
CONTA TEXTO 20

TB_COMISSOES
=============
ID_COMISSAO INTEIRO LONGO AUTONUMERAÇÃO
ID_VENDEDOR INTEIRO LONGO
ID_TIPO_COMISSAO INTEIRO LONGO
COMISSAO DUPLO
LEMBRETE TEXTO 250

TB_TIPOS_ELETRONICOS
=====================
ID_TIPO INTEIRO LONGO AUTONUMERAÇÃO
DESCRICAO TEXTO 60

TB_TIPOS_LOGRADOUROS
=======================
ID_LOGRADOURO INTEIRO LONGO AUTONUMERAÇÃO
DESCRICAO TEXTO 25
SIGLA TEXTO 04

TB_BANCOS
===========
ID_BANCO INTEIRO LONGO AUTONUMERAÇÃO
DESCRICAO TEXTO 40
SIGLA TEXTO 10
CODIGO TEXTO 04

TB_TIPOS_COMISSOES
===================
ID_TIPO_COMISSAO INTEIRO LONGO AUTONUMERAÇÃO
DESCRICAO TEXTO 60

Foram adicionadas tabelas de suporte.
- TB_TIPOS_COMISSOES permite ao usuário do sistema cadastrar um número indefinido de comissões, de forma que nem todo vendedor precisará ter um dado tipo de comissão, nem a aplicação estará eternamente "amarrada" aos tipos pré-definidos pela estrutruraanterior.
- TB_BANCOS, obviamente mantém o cadastro de todos os bancos, de forma que não haverão entradas discrepantes e que acabam com qualquer bom trabalho, como registros de "intenção" (237 - BRADESCO / 237 - BANCO BRASILEIRO DE DESCONTOS, por exemplo).
- TB_TIPOS_LOGRADOUROS permite, da mesma forma que a TB_BANCOS, reduzir a massa de textos á ser digitada, sem manter a aplicação com dados fixados por código, o que é bastante incoerente. Da mesma forma que evita a redundà¢ncia, também evita entradas "falsas", como a do exemplo anterior.
- TB_TIPOS_ELETRONICOS permitirá que não apenas um e-mail e um site sejam cadastrados por vendedor, e não apenas mais de um endereço, mas também tipos diferentes, como endereços UIN (ICQ) e IDs MSN, AOL etc. Se amanhã surgir uma nova modalidade de endereçamento ou contato eletrà'nico, a aplicação continuará trabalhando sem quaisquer alterações, ao contrario do que ocorre com a estrutura colossal.

Como dá para perceber, com esta reestruturação, cada vendedor poderá ter mais de um endereço, conta bancária, tipos de comissão e endereços eletrà'nicos, sem que seja necessário repetir a massa de dados de campos-texto por todo o conjunto. A base de dados fica menor, a quantidade de índices possíveis, mais estáveis, aumenta e a carga de cada informação é mais rápida.

Em têrmos de normatização, essa pequena alteração está longe ainda de ser um exemplo perfeito, mas já dá para formar uma idéia da coisa. Como você vai notar, nenhuma das tabelas tem mais de 15 campos, todas serão funcionais, rápidas e "enxutas". E no momento de carregar á grade TODAS as informações, simultaneamente, você ainda poderá fazer uso do MSHFlexGrid, que dá uma excelente apresentação de dados hierárquica, usando apenas uma única instrução SQL.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Relativamente ao uso de diversos DB MS-Access:

Utilizar um DB por tabela, á primeira vista, pode parecer até exagero. Mas não é, caso as previsões de expansão dos dados sejam maciças.
Vários cuidados devem ser levados em consideração, para evitar problemas com a manutenção DBA e com a integridade.
Por exemplo, isso você já deve saber e usar de forma corrente, encerrar todas as conexões e atribuir um Nothing á todos os objetos de acesso á dados, assim que os deixar de utilizar.
A estrutura física da rede também é de importà¢ncia relevante, dado que pontos de rede com falhas esporádicas de conexão podem corromper as bases de dados.
Ao trabalhar com várias bases, com o tempo, elas se "encorpam". Com esse crescimento, o desempenho tende á diminuir, o que é visto pelos usuários como uma deficiência da aplicação e não do engine de dados.

Para minimizar esse impacto, existem formas alternativas de trabalho com o MS-Access / ADO, que oneram um pouco seu trabalho de codificação, mas garantem a qualidade de seu produto. Uma delas, a mais complicadinha, porém mais eficiente, é a geração de componentes de serviço, na forma de DLLs ou EXEs, residentes em um equipamento servidor. O acesso aos dados é realizado por esses componentes, nunca pela aplicação-cliente. A aplicação-cliente, por sua vez, requisita aos componentes citados que executem instruções SQL, retornando ou não recordsets do tipo ADO.
Outra forma é a de utilizar-se de uma base de dados local, por exemplo, na pasta TEMP, vinculando todas as tabelas das demais bases de dados nesta primeira. A base é criada na inicialização do sistema e a vinculação das tabelas garante que todos os objetos estarão presentes e no local esperado antes de o usuário começar seu trabalho. No encerramento do aplicativo, os vínculos são removidos e a base local é eliminada. O inconveniente deste processo é que há uma certa demora na inicialização do sistema, mas que pode ser compensada visualmente com um formulário de Splash, posicionando o usuário sobre os processos em andamento, da mesma forma que trabalham aplicações como o Adobe ou o Corel Draw.

Mas se até o presente momento você não se deparou com quaisquer perdas sensíveis de desempenho, em minha opinião pessoal, o melhor é manter as bases separadas exatamente como estão hoje. Quando fà'r o caso, se optar pelo ADO mais tarde, aí sim, talvês notará o problema. De qualquer forma, fica a dica.

Ah, mais uma: Caso venha a adotar o ADO, evite utilizar-se de ODBC para acessar os dados. Prefira sempre utilizar o DSN do servidor e a string de conexão completa do driver do MS-Access, pois o desempenho é bem melhor.

E por hoje é só, creio. Estou de saída para a Alfà¢ndega e depois aos terminais, então, mais uma vez, não dá tempo de entrar em maiores detalhes. Sorry.

USUARIO.EXCLUIDOS 29/12/2004 10:19:44
#57557

P.S.: O erro é, como eu disse, haver um REGISTRO muito grande. A quantidade de caracteres somada entre todos os campos de um registro NÃO deve ser superior á 2000. Em algum momento, supostamente há uma quantidade superior.

USUARIO.EXCLUIDOS 29/12/2004 15:57:21
#57649

Oi, olá e boas tardes!

KPELLAJR: A pretensão foi unica e apenas a de exemplificar como poderia ser normatizada a tabela de vendedores. Em hipótese alguma esse processo finda exatamente como o exemplo, pode ser indefinidamente remodelado. Em relação ao conjunto CIDADE / BAIRRO, é uma opção excelente, juntamente aos campos CEP, LOGRADOURO, UF etc, todos vinculados á tabela de CEP dos Correios, validando também a entrada de dados.

E não discordo de você LAERTE, não há quaisquer normas que obriguem o desenvolvedor a se favorecer de uma boa normatização. Aliás, meu ganha-pão vem justamente das milhares de estruturas mal dimensionadas em empresas dos mais variados portes. Dessa forma, até agradeço se ninguém se valer da ferramenta da normatização, pois garantem meu dia-á-dia.

O que eu coloquei é apenas uma pequena parte de um resumo do que tenho assimilado ao longo de 25 anos de atividades em desenvolvimento de sistemas, desde o saudosíssimo CP/M (alguém lembra do comando PIP?), entre análise e programação. Não pretendi em momento algum criar nenhuma plataforma de espelhamento, menos ainda alguma tábua de regras invioláveis.

Aliás, o que eu escreví é como o Sol, aqui em Santos: Ele existe sempre e brilha todos os dias, mas só vai á praia quem quer, quem gosta ou quem pode.

USUARIO.EXCLUIDOS 02/01/2005 02:53:33
#58126

Comentário sobre engine de dados x biblioteca de acesso á dados:

Ao optar pelo MS-Access, que tem, sem dúvidas, suas vantagens, o mecanismo DAO permite, em uma só biblioteca, realizar todas as operações necessárias de acesso e manutenção de dados, coisa que a ADOX não faz sem o uso ao menos da ADOX. Além desse fator, a DAO apresenta invariavelmente resultandos de melhor desempenho, frente a ADO, pois trata-se de uma biblioteca especializada, focada ao MS-Access e demais engines Jet.

Ao projetar uma aplicação que utiliza a DAO, a mesma poderá utilizar-se de linguagem DDL da SQL para criar, alterar e manter os dados, bem como utilizar os objetos próprios da bilbioteca. Em ambos os casos, os resultados serão satisfatórios, portanto, se deseja "fechar questão" no MS-Access, os objetos DAO podem ser uma alternativa bastante interessante. Se, por outro lado, desejar manter compatibilidade com os demais engines, incluindo aqueles não abrangidos pela DAO, mesmo que não se utilize inicialmente da ADO, o passo mais importante será a familiaridade com a linguagem SQL, tanto no que tange a formação de consultas de tipos variados (consultas simples ou parametrizadas, de retorno ou de ação), quanto ao tópico de manutenção da base de dados e suas estruturas.

Com relação aos dados.
Normalmente se fornece apenas as informações mais usuais, abrindo as possibilidades de o cliente incluir as suas próprias informações. Isto varia em acordo com o modelo de projeto, ou seja, em se tratando de um sistema comercial fechado para qualquer empresa, fornecer dados mais amplos é interessante por reduzir o volume de trabalho na customização, mas em se tratando de desenvolvimento mais específico, empresa á empresa, apenas os dados básicos são o mais conveniente, desde que o cliente seja suprido com mecanismos para moldar os dados ao seu modo.

Apesar de ser a idéia mais comum, a de ter a base de dados inicial já formada por todos os registros de tipos de logradouro e cidades, não considero como a melhor idéia. Explico: Como a aplicação será utilizada e por quem são pontos-chave nessa questão. Normalmente não há efetivo interesse de um cliente em manter tipos de logradouro pouco comuns, nem itens que não serão utilizados. Assim, havendo a abertura da composição de endereços, por exemplo, uma empresa de pequeno porte na cidade de São Paulo pode não se interessar por um cadastro com todas as cidades do estado, assim como uma empresa de médio porte pode solicitar cidades e códigos de endereçamento internacionais. Cada coisa têm seu lugar próprio. Se seu sistema não é um sistema especialista em B.I. em têrmos nacionais, adir nele uma série completa de tabelas com todos os códigos de ruas do país só fará com que o mesmo ocupe mais espaço, sendo que o cliente nem sempre irá reconhecer o poder de tal ferramenta. Em minha opinião, o ideal é o estudo de caso, com a inclusão do básico para que o sistema possa evoluir em acordo com as necessidades do cliente, e não antes dele.

Para traçar um paralelo, a maioria dos clientes, ao receber um sistema bem completo e com dados já equacionados para um crescimento maior do que a empresa suspeita, a visão do cunjunto acaba passando a falsa idéia de uma complexidade maior e de uma operacionalidade difícil de manter. O sistema passa á ser subutilizado e suas potencialidades normalmente são nati-mortas.

é como abrir uma auto-escola com uma frota de Ferrari. Os alunos querem aprender a dirigir, não se darão ao trabalho de apreciar o veículo que estarão utilizando e, caso algum o faça, levará muito mais tempo para aprender. O melhor é ensinar com um bom carro popular, fazer o aluno passar por todas as agruras e apertos que o dia-á-dia trará e, somente quando o aluno sentir-se capaz, passar para um veículo mais "interessante".

Procure manter índices simples unívocos como chave primária, ou seja, evite sempre que possível o uso de chaves compostas.

Você cita:

"...ou seja: teriamos as tabelas TbTipoLogradouro, TbLogradouros, Tbbairros, TbCidades, TbUfs, TbBancos e etc que seriam usadas por todas as outras tabelas... é isso???..."

Sim, é essa a idéia. Uma só tabela com os dados de todos os bancos (por exemplo) e em cada tabela que utilize esses dados, apenas o campo de chave primária da tabela de bancos, ao invés de todos os demais dados, repetidamente.
Não há a necessidade de gerar relacionamentos explícitos via MS-Access, uma vez que você pode apenas relacionar as tabelas com as devidas instruções SQL necessárias e isso também poupa espaço e aumenta desempenho.

"...e assim que eu mudasse um dado de um vendedor, ele sairia alterando todos os registros em todas as tabelas por causa das relações??? (tipo, vendedor relaciona com clientes que relaciona com vendas que relaciona com fornecedor q relacina com financeiro, etc) ..."

Bem, este é um modo de trabalho que pode / deve ser ajustado por você. Por exemplo, em um primeiro nível, se em sua tabela de Bancos um nome de banco for alterado, por estar vinculada á outras tabelas, não alterará absolutamente nada além disso, mas a alteração estará espelhada em todas as tabelas relacionadas. Em um segundo nível, você pode ter um campo com o ID do vendedor e outro do cliente na tabela de faturas. Ao tentar excluir esse cliente ou esse vendedor, você pode fazer com que o engine não permita essa exclusão, senão quando as faturas vinculadas á eles estiverem completamente quitadas, saindo da tabela de faturas e entrando em uma tabela de arquivo-morto. Caso o nome do vendedor seja alterado, da mesma forma que o explicado para a tabela de bancos, a ação será espelhada na fatura, apesar de somente haver sido feita.alteração na tabela de vendedores.

"...e na hora de mostrar por exemplo, as contas bancarias de um cliente que podem variar de 1 a 10, 20, mil, sei lá... que controle utilizo, um grid que vai filtrar apenas as contas bancarias relacionadas com aquele cliente? e para fazer isso??? tem apostila de flexgrid no site??? pois eu só uso o DbGrid... (Dinossauro... eu sei... podem xingar...) ...."

Olha, o dbGrid é dinossauro, sim, mas não um dinossaurozinho qualquer como os Sherindan 3D. Trata-se de um excelente mecanismo de apresentação de dados, bastante customizável e totalmente editável. Um dinossauro "de peso". Para o uso com o DAO, é a melhor escolha (sem contar controles de terceiros como o TdBGrid ou o VSGrid, que só podem ser distribuidos com as devidas licenças, não tão baratas). Já com o ADO, os controles DataGrid, MSFlexGrid e MSHFlexGrid são as opções mais frequêntes. As capacidades mais interessantes do MSHFlexGrid dizem respeito á apresentação de dados hierárquica, ou seja, uma célula pode apresentar, por exemplo, a data de hoje e ser hierarquicamente dividida em várias linhas, cada qual com um vendedor diferente, que realizou alguma operação de venda no dia, e essa linha com o vendedor, por sua vez, pode ser subdividida em diversas outras linhas, cada qual com uma fatura diferente, emitidas no mesmo dia, pelo mesmo vendedor. Mas nem a MSFlexGrid nem a MSHFlexGrid são diretamente editáveis. Esta capacidade (edição) só se consegue com artifícios, que são apresentados, sim, aqui no site. Há, portanto, bom e farto material para sua "degustação" aqui presente.

"...que tipo de controle eu devo utilizar para mostrar todos os bairros cadastrados??..."
Você pode optar por controles DataCombo (ADO) / dbCombo (DAO), populando-os durante a carga do formulário, diretamente com as tabelas de suporte em questão. As propriedades RowSource (ligada ao recordset), ListField (ligada ao campo que deverá ser listado, como o nome do banco por exemplo) e BoundColumn (ligada ao campo com conteúdo á ser gravado, como 237 por exemplo) são as utilizadas para essa tarefa e o valor de retorno, quando devidamente selecionado, estará na propriedade BoundText dos controles. Ligando BoundColumn á um campo numérico unívoco, como um de Autonumeração, você irá obter os melhores resultados. Para saber se a escolha é inválida, verifique se a propriedade BoundText é Empty e em seguida, se é um valor numérico.

Outra dica que poucos adotam é evitar á todo custo o uso de DataControls ou adodcDatas, que fazem conexão direta e paralela com os serviços de dados. Eu peguei uma aplicação recentemente com poucas telas, que mantinha 4200 conexões diferentes simultà¢neas ao serviço. O problema, quando me contataram, era que o servidor estava exaurido. Hoje, o número máximo de conexões simultà¢neas caiu para 320, ou seja, duas por máquina e mesmo assim, porque eu ainda não terminei o trabalho.

O Renato cita:
"...No VB até tem ocx que faz a consulta para vc e tal, já vi, mas eu não uso, prefiro fazer tudo na mão mesmo...." - Preste muita atenção nessa dica, pois ela vale ouro.Tudo aquilo que você desenvolve, você controla, adapta, altera. Tudo o que você apenas usa, depende de outras empresas para melhorar e, muitas vezes, acaba sumindo do mercado, sem suporte nenhum. Ano passado acabou o suporte ao Microsoft Visual Basic for Dos 1.0, o que é um tempo bastante bom, desde 1987, mas várias linguagens e engines sumiram sem deixar vestígios nesse mesmo período, sem que os fabricantes desse maiores explicações.

E, respondendo sua outra questão, acho que não é ressaca, só. Assim que deu dia 31, eu praticamente "desmaiei", só acordei há pouco. Mas é cansaço, mesmo. E depois de amanhã é "dia de briga" novamente.

Valew?