ERRO 3047 - RECORD TOO LARGE
que catzo de erro é esse??? é bnem no meio do cadastro de produtos que é ENORME!!!!! eu entupo todos os campos de caracteres, mas tem uns 44 campinhos que não aceitam e dá este erro... não achei documentação referemnte a esse erro no msdn... alguem sabe dizer o q significa??? e como evitar???
Marcelo, desculpe a intrusão.
De fato, os conceitos de gerenciamento de dados vêm se aperfeiçoando ao longo dos últimos anos. O conceito de banco de dados relacional, apesar de haver sido esboçado ainda em D.O.S. (leia-se Clipper / dBase, hehehe), nunca foi muito adiante antes de gerenciadores como o Oracle.
Mas depois deste passo, as regras de normatização de dados foram se aperfeiçoando para permitir desempenho e confiabilidade. Não se espante, pois é um entre centenas de desenvolvedores que, por qualquer razão, seja falta de tempo ou por não ter ainda sofrido revés, não se fixam muito nessas regras.
Apesar disso, são regras que poupam centenas de linhas em código, tornam a manutenção de sistemas bem mais fácil e aumentam sensivelmente o desempenho das aplicações. Seus clientes agradecem, hehehe.
Algumas dessas regras você pode verificar se está infringindo de forma fácil. Por exemplo, todas as suas tabelas devem possuir um campo primário (ou chave) único, preferencialmente de tipo numérico e geralmente de autonumeração.
Caso vários registros de uma mesma tabela possuam em um campo texto o mesmo conteúdo (por exemplo, em Forma_pagto, o valor "à  VISTA"), é porque esse campo é, na verdade, uma tabela separada.
Se um campo texto possui partes comuns em vários registros, isso indica que esse campo é, na verdade, vários campos. Ex.: Campo Endereco com Valores do tipo "RUA TAL", "RUA QUAL", "AV.ISSO", "AV.AQUILO"... Na verdade, os campos são Logradouro ("TAL", "QUAL", "ISSO", "AQUILO" etc) e Tipo_de_logradouro("Rua", "Avenida", "Alameda" etc). Novamente, quando vários registros apresentam o mesmo conteúdo, deve-se pensar em uma tabela secundária, ou seja, para o exemplo, uma tabela de tipos de logradouro compõe o endereço.
Campos nulos não entram na composição de aquivos de Ãndice, em nenhum engine de dados, quer sejam Microsoft ou não. Desta forma, campos que aceitam valores nulos tornam a aplicação mais lenta e pesada, pois precisam carregar o conjunto de registros completo para avaliar cada registro com campos nulos somente depois da carga.
Caso você utilize campos data, NÃO deve utilizar instruções de seleção do tipo "WHERE NOT DATA_INICIO IS NULL" OU "WHERE NOT ISNULL(DATA_INICIO)", mas utilizar-se de uma faixa de datas válida e conhecida.
A quantidade de campos em uma tabela deve ser limitada. Quanto menor esse número, mais ágil será sua carga. O valor que se costuma utilizar como limite virtual é de 15 campos por tabela média. Caso sejam necessárias informações complementares, estude o grau de informações de forma á tornar uma tabela com grande número de campos em várias tabelas vinculadas. Por exemplo, não se deve criar uma tabela de FATURAS onde todos os itens faturados estejam na mesma tabela, mas sim, duas tabelas, uma com o cabeçalho da fatura e outra com os itens.
A quantidade de Ãndices é também fundamental. Um número excessivo de Ãndices pode causar um delay maior do serviço, assim como a ausência de Ãndices. O número considerado "aceitável" de Ãndices por tabela é de 5, tomando-se por base a tabela de estrutura média, com até 15 campos. Ou seja, 1/3 de campos como Ãndices.
Agora, vamos ao erro.
Se o erro fosse "...FIELD TOO LARGE..." eu concordaria com o Jose.Niz. Algum campo estaria sobrecarregado, além do tamanho definido na estrutura de dados.
Mas o erro apresentado avisa que o registro (todo o conjunto de campos) é muito grande para ser administrado pelo serviço de dados. O que isso significa? Que o gerenciador que você está usando não tem capacidade para administrar essa quantidade de informações. Ou ainda, que o espaço de trabalho do serviço não pode ser otimizado para tal tamanho.
Com campos texto de tamanho limitado, esse erro é mais comum em bases de dados do Jet, que também apresenta graves falhas de gerenciamento de consultas (views ou stored procedures). Para resolver, somente limitando os campos texto em valores mais baixos.
Com campos do tipo MEMO, porém, essa falha ocorre TAMBéM em serviços mais estáveis, como os do SQL Server e do próprio Oracle. E afinal, o que é isso, no caso dos campos MEMO? Significa que o limite, em bytes, para a média dos registros, será ampliado para que todos os registros possam conter valores similares.
Assim, ao incluir um ou mais campos MEMO, todo o conjunto é alterado antes. Se o espaço reservado para trabalho não comportar esse redimensionamento, o erro retornado será exatamente esse apontado. No SQL Server, um paliativo seria aumentar o tamanho do buffer de registro, bem como a taxa de crescimento do banco. No Oracle, aumentar os espaços de trabalho e as áreas de Ãndices.
Mas essas "soluções" são meramente paliativos pontuais. Se, em um primeiro momento, resolvem, na sequência acaba o espaço reservado e o próprio desempenho e confiabilidade passam á ser comprometidos.
A solução efetiva é mesmo a normatização de dados, o que deve lhe consumir um bom tempo, uma vez que ainda não está acostumado á utilizar-se dessa ferramenta. Mais uma vez, não se intimide com os têrmos técnicos. Tudo é muito simples, depois de você haver entendido as regras. E ninguém nasceu conhecendo essas regras, que estão mesmo em constante evolução.
Acredito que todos os colegas aqui no site não se oporiam em auxiliá-lo nessa tarefa, ao menos até que o conceito fique mais firmado para você.
Espero ter ajudado.
De fato, os conceitos de gerenciamento de dados vêm se aperfeiçoando ao longo dos últimos anos. O conceito de banco de dados relacional, apesar de haver sido esboçado ainda em D.O.S. (leia-se Clipper / dBase, hehehe), nunca foi muito adiante antes de gerenciadores como o Oracle.
Mas depois deste passo, as regras de normatização de dados foram se aperfeiçoando para permitir desempenho e confiabilidade. Não se espante, pois é um entre centenas de desenvolvedores que, por qualquer razão, seja falta de tempo ou por não ter ainda sofrido revés, não se fixam muito nessas regras.
Apesar disso, são regras que poupam centenas de linhas em código, tornam a manutenção de sistemas bem mais fácil e aumentam sensivelmente o desempenho das aplicações. Seus clientes agradecem, hehehe.
Algumas dessas regras você pode verificar se está infringindo de forma fácil. Por exemplo, todas as suas tabelas devem possuir um campo primário (ou chave) único, preferencialmente de tipo numérico e geralmente de autonumeração.
Caso vários registros de uma mesma tabela possuam em um campo texto o mesmo conteúdo (por exemplo, em Forma_pagto, o valor "à  VISTA"), é porque esse campo é, na verdade, uma tabela separada.
Se um campo texto possui partes comuns em vários registros, isso indica que esse campo é, na verdade, vários campos. Ex.: Campo Endereco com Valores do tipo "RUA TAL", "RUA QUAL", "AV.ISSO", "AV.AQUILO"... Na verdade, os campos são Logradouro ("TAL", "QUAL", "ISSO", "AQUILO" etc) e Tipo_de_logradouro("Rua", "Avenida", "Alameda" etc). Novamente, quando vários registros apresentam o mesmo conteúdo, deve-se pensar em uma tabela secundária, ou seja, para o exemplo, uma tabela de tipos de logradouro compõe o endereço.
Campos nulos não entram na composição de aquivos de Ãndice, em nenhum engine de dados, quer sejam Microsoft ou não. Desta forma, campos que aceitam valores nulos tornam a aplicação mais lenta e pesada, pois precisam carregar o conjunto de registros completo para avaliar cada registro com campos nulos somente depois da carga.
Caso você utilize campos data, NÃO deve utilizar instruções de seleção do tipo "WHERE NOT DATA_INICIO IS NULL" OU "WHERE NOT ISNULL(DATA_INICIO)", mas utilizar-se de uma faixa de datas válida e conhecida.
A quantidade de campos em uma tabela deve ser limitada. Quanto menor esse número, mais ágil será sua carga. O valor que se costuma utilizar como limite virtual é de 15 campos por tabela média. Caso sejam necessárias informações complementares, estude o grau de informações de forma á tornar uma tabela com grande número de campos em várias tabelas vinculadas. Por exemplo, não se deve criar uma tabela de FATURAS onde todos os itens faturados estejam na mesma tabela, mas sim, duas tabelas, uma com o cabeçalho da fatura e outra com os itens.
A quantidade de Ãndices é também fundamental. Um número excessivo de Ãndices pode causar um delay maior do serviço, assim como a ausência de Ãndices. O número considerado "aceitável" de Ãndices por tabela é de 5, tomando-se por base a tabela de estrutura média, com até 15 campos. Ou seja, 1/3 de campos como Ãndices.
Agora, vamos ao erro.
Se o erro fosse "...FIELD TOO LARGE..." eu concordaria com o Jose.Niz. Algum campo estaria sobrecarregado, além do tamanho definido na estrutura de dados.
Mas o erro apresentado avisa que o registro (todo o conjunto de campos) é muito grande para ser administrado pelo serviço de dados. O que isso significa? Que o gerenciador que você está usando não tem capacidade para administrar essa quantidade de informações. Ou ainda, que o espaço de trabalho do serviço não pode ser otimizado para tal tamanho.
Com campos texto de tamanho limitado, esse erro é mais comum em bases de dados do Jet, que também apresenta graves falhas de gerenciamento de consultas (views ou stored procedures). Para resolver, somente limitando os campos texto em valores mais baixos.
Com campos do tipo MEMO, porém, essa falha ocorre TAMBéM em serviços mais estáveis, como os do SQL Server e do próprio Oracle. E afinal, o que é isso, no caso dos campos MEMO? Significa que o limite, em bytes, para a média dos registros, será ampliado para que todos os registros possam conter valores similares.
Assim, ao incluir um ou mais campos MEMO, todo o conjunto é alterado antes. Se o espaço reservado para trabalho não comportar esse redimensionamento, o erro retornado será exatamente esse apontado. No SQL Server, um paliativo seria aumentar o tamanho do buffer de registro, bem como a taxa de crescimento do banco. No Oracle, aumentar os espaços de trabalho e as áreas de Ãndices.
Mas essas "soluções" são meramente paliativos pontuais. Se, em um primeiro momento, resolvem, na sequência acaba o espaço reservado e o próprio desempenho e confiabilidade passam á ser comprometidos.
A solução efetiva é mesmo a normatização de dados, o que deve lhe consumir um bom tempo, uma vez que ainda não está acostumado á utilizar-se dessa ferramenta. Mais uma vez, não se intimide com os têrmos técnicos. Tudo é muito simples, depois de você haver entendido as regras. E ninguém nasceu conhecendo essas regras, que estão mesmo em constante evolução.
Acredito que todos os colegas aqui no site não se oporiam em auxiliá-lo nessa tarefa, ao menos até que o conceito fique mais firmado para você.
Espero ter ajudado.
Buenas!
é uma excelente notÃcia, que você tenha gostado das respostas, e que tenha se animado em atualizar seus conhecimentos.
Você vai ver que há enormes vantagens em adotar não apenas a normatização básica, mas também a padronização (usar nomes de campos, tabelas, consultas etc que tenham prefixo, informação sucinta e sufixo, por exemplo), bem como na generalização de funções.
Com o tempo, você terá um ferramental capaz de lidar com diversos engines ao mesmo tempo, de forma segura e confiável, e o que é melhor, sem perder tempo re-programando.
Com relação á utilização de vários MDB concomitantes, não há nenhuma restrição lógica ou fÃsica á esse método. é seguro, bem interessante e acaba propiciando mais confiabilidade aos dados, já que as bases tendem á "crescer" menos.
Há apenas as restrições impostas pelo engine, que são as de manter "apenas" 254 bases simultà ¢neas, OU até 2GBytes de dados no conjunto de espaços de trabalho, não propiciar um serviço de dados, mas carregar todo o conjunto das consultas ao terminal cliente, não possuir um conjunto sólido de RollBack por pacotes, delegar os serviços de segurança aos MDA etc.
Se você está usando vários MDB, saiba que é quase assim que o SQL Server trabalha, sendo que cada um de seus esquemas de dados corresponde á um arquivo e os demais objetos (users, indices etc) em outros. Então, não está errado e mais do que isso, é até aconselhável, se pretende continuar com o uso do MS-Access.
Na medida em que fà 'r tomando mais confiança com a normatização, procure gerar funções VB que possam lidar com situações de consulta e acesso geral ( leitura e escrita ), de forma á não se prender ao SQL do Access, mas sim, utilizar a linguagem SQL mais genérica possÃvel. Dessa forma, as mesmas funções irão "rodar" em outros engines e você poderá migrar suas aplicações sem sofrer consequências muito grandes.
Por fim, mais uma vez, não esqueça de que você é um ser humano, como outro qualquer. Todos temos dúvidas sobre tudo, e teremos sempre enquanto estivermos vivos. E essas dúvidas não devem "morrer" com você. Por mais que você se sinta conformtável, não hesite em procurar auxÃlio, mesmo que seja para uma "dúvidazinha besta", se é que isso existe.
Uma vez eu ouvi um comentário do Sr. OTA, no STEFZS. Ele dizia: "Essa minha equipe é a melhor que existe, a melhor que eu já tive em mais de dez anos, porque ninguém sabe nada, nunca, mas ninguém desiste antes de achar a resposta."
Nunca mais esqueci esse comentário.
é uma excelente notÃcia, que você tenha gostado das respostas, e que tenha se animado em atualizar seus conhecimentos.
Você vai ver que há enormes vantagens em adotar não apenas a normatização básica, mas também a padronização (usar nomes de campos, tabelas, consultas etc que tenham prefixo, informação sucinta e sufixo, por exemplo), bem como na generalização de funções.
Com o tempo, você terá um ferramental capaz de lidar com diversos engines ao mesmo tempo, de forma segura e confiável, e o que é melhor, sem perder tempo re-programando.
Com relação á utilização de vários MDB concomitantes, não há nenhuma restrição lógica ou fÃsica á esse método. é seguro, bem interessante e acaba propiciando mais confiabilidade aos dados, já que as bases tendem á "crescer" menos.
Há apenas as restrições impostas pelo engine, que são as de manter "apenas" 254 bases simultà ¢neas, OU até 2GBytes de dados no conjunto de espaços de trabalho, não propiciar um serviço de dados, mas carregar todo o conjunto das consultas ao terminal cliente, não possuir um conjunto sólido de RollBack por pacotes, delegar os serviços de segurança aos MDA etc.
Se você está usando vários MDB, saiba que é quase assim que o SQL Server trabalha, sendo que cada um de seus esquemas de dados corresponde á um arquivo e os demais objetos (users, indices etc) em outros. Então, não está errado e mais do que isso, é até aconselhável, se pretende continuar com o uso do MS-Access.
Na medida em que fà 'r tomando mais confiança com a normatização, procure gerar funções VB que possam lidar com situações de consulta e acesso geral ( leitura e escrita ), de forma á não se prender ao SQL do Access, mas sim, utilizar a linguagem SQL mais genérica possÃvel. Dessa forma, as mesmas funções irão "rodar" em outros engines e você poderá migrar suas aplicações sem sofrer consequências muito grandes.
Por fim, mais uma vez, não esqueça de que você é um ser humano, como outro qualquer. Todos temos dúvidas sobre tudo, e teremos sempre enquanto estivermos vivos. E essas dúvidas não devem "morrer" com você. Por mais que você se sinta conformtável, não hesite em procurar auxÃlio, mesmo que seja para uma "dúvidazinha besta", se é que isso existe.
Uma vez eu ouvi um comentário do Sr. OTA, no STEFZS. Ele dizia: "Essa minha equipe é a melhor que existe, a melhor que eu já tive em mais de dez anos, porque ninguém sabe nada, nunca, mas ninguém desiste antes de achar a resposta."
Nunca mais esqueci esse comentário.
Tópico encerrado , respostas não são mais permitidas