NOME DO CAMPO AUSENTE NO BD ACCESS - ERRO 3265
Pessoal muitas vezes eu preciso apresentar o conteudo de um campo assim:
Msgbox ControleData.RecordSet!NomedoCampo
Mas se o campo não existe, o VB6 me retiorna o erro 3265, é claro.
Eu sempre uso o tratamento de erro para que o programa não seja encerrado e apresente uma mensagem ao usuario que existe um campo ausente na tabela.
O problema é que não sei ainda como fazer que o VB6 me diga o nome do campo ausente.
Eu preciso que ao não encontrar o campo ele informe que houve o erro 3265 + o niome do campo que não existe.
Obs. Mesmo havendo muitas criticas eu uso DataControl + DAO para me conectar com o Banco de dados Access.
olha eu acho que seu problema é simples
se vc tenta exibir o conteudo de um campo passando o nome do campo para o recordset assim
Msgbox ControleData.RecordSet![txt-color=#0000f0]CampoNome[/txt-color]
e der um erro que este campo não existe, então pela lógica o campo que não existe é [txt-color=#0000f0]CampoNome[/txt-color]
ou seja o campo que vc solicitou, não existe então é ele mesmo o campo que não existe.
se vc tenta exibir o conteudo de um campo passando o nome do campo para o recordset assim
Msgbox ControleData.RecordSet![txt-color=#0000f0]CampoNome[/txt-color]
e der um erro que este campo não existe, então pela lógica o campo que não existe é [txt-color=#0000f0]CampoNome[/txt-color]
ou seja o campo que vc solicitou, não existe então é ele mesmo o campo que não existe.
ola Marcelo Treze,
Aà é que está o problema. Na ausencia do campo na tabela, o VB6 informa: [Ô]Run Time erro [ô]3265[ô] [ô]Item não encontrado na nesta coleção[ô] , Mas não informa o nome do campo em que ele [ô]tropeçou[ô].
Aà é que está o problema. Na ausencia do campo na tabela, o VB6 informa: [Ô]Run Time erro [ô]3265[ô] [ô]Item não encontrado na nesta coleção[ô] , Mas não informa o nome do campo em que ele [ô]tropeçou[ô].
ROBSON, leia a resposta do MARCELO com calma...
Robson então vou tentar melhorar a resposta do Marcelo para você.
Toda rotina crÃtica que pode gerar erros e ruptura do sistema, deve ter uma rotina de tratamento, até aqui acho que você já sabe.
então o que precisa é fazer essa rotina de forma eficiente.
Eu tenho um sistema onde, além de interceptar o erro, ele identifica o que estava fazendo, onde e em que linha o erro ocorreu.
Depois emite um aviso ao usuário, gera um arquivo de log e volta a execução depois de tratar o erro.
Agora estou implementando uma nova rotina que enviará o Log direto para meu email, com o nome do cliente e usuário/micro, assim ficará mais fácil identificar e corrigir, pois os usuários só comunicam 20% dos erros, segundo minha estatÃstica nos clientes.
Como fazer:
1- cria duas variável públicas num módulo (ex: sNomeForm e sAcao)
2- No load de cada form inclui a identificação dele ex: sNomeForm = me.Name
3- Ao executar cada rotina que possa gerar um erro crÃtico ex: acesso a banco de dados, leitura e escrita de arquivos externos, etc... identifique isso ex: sAcao = [Ô]Acessando banco xxx[Ô]
4- na rotina acionada pelo erro, você identifica, trata e pega essas informações, inclusive o nome da própria rotina (evento, métodos, etc...)
OBS: Segundo seu problema, se você está acessando no recordset um campo que não existe no banco, então vou lhe dar duas orientações que aprendi na prática e em pesquisas sobre desempenho de acesso a dados:
1- você deve estar usando algo assim: Select * From tabela....etc... isso causa uma lentidão maior na consulta do que se declarar os campos que realmente deseja, mesmo que sejam todos da tabela como: Select tab.campo1, tab.campo2, etc.... From tab ......etc...
Isso porque o select precisará identificar cada campo existente na tabela antes de selecioná-lo. Assim a segunda opção, apesar de mais trabalhosa e deixar seu código mais extenso, será executada mais rapidamente e evitará esse problema que citou. Pois se ocorrer o erro será já no Select e não dentro do recordset, uma vez que teria de usar a variável sAcao em cada campo que fosse usar, deixando inviável.
2- Outra pratica é sempre sempre que implementar um campo na tabela, fazer o ajuste no código. Pois não dá para entender como pode ter no código:
Msgbox ControleData.RecordSet!CampoNome
Mas o campo não existir na tabela. Isso é o mesmo que incluir uma nova OCX no projeto e não distribuir no instalador.
Há várias regras e práticas em informática para evitar problemas como esse, e principalmetne para otimizar código com classes e funções, além de melhorar o desempenho ex:
Abrir e fechar o banco a cada acesso
destruir todos os objetos quando fechar um form ou o sistema
declarar e inicializar as variaveis corretamente, ex:
Toda rotina crÃtica que pode gerar erros e ruptura do sistema, deve ter uma rotina de tratamento, até aqui acho que você já sabe.
então o que precisa é fazer essa rotina de forma eficiente.
Eu tenho um sistema onde, além de interceptar o erro, ele identifica o que estava fazendo, onde e em que linha o erro ocorreu.
Depois emite um aviso ao usuário, gera um arquivo de log e volta a execução depois de tratar o erro.
Agora estou implementando uma nova rotina que enviará o Log direto para meu email, com o nome do cliente e usuário/micro, assim ficará mais fácil identificar e corrigir, pois os usuários só comunicam 20% dos erros, segundo minha estatÃstica nos clientes.
Como fazer:
1- cria duas variável públicas num módulo (ex: sNomeForm e sAcao)
2- No load de cada form inclui a identificação dele ex: sNomeForm = me.Name
3- Ao executar cada rotina que possa gerar um erro crÃtico ex: acesso a banco de dados, leitura e escrita de arquivos externos, etc... identifique isso ex: sAcao = [Ô]Acessando banco xxx[Ô]
4- na rotina acionada pelo erro, você identifica, trata e pega essas informações, inclusive o nome da própria rotina (evento, métodos, etc...)
OBS: Segundo seu problema, se você está acessando no recordset um campo que não existe no banco, então vou lhe dar duas orientações que aprendi na prática e em pesquisas sobre desempenho de acesso a dados:
1- você deve estar usando algo assim: Select * From tabela....etc... isso causa uma lentidão maior na consulta do que se declarar os campos que realmente deseja, mesmo que sejam todos da tabela como: Select tab.campo1, tab.campo2, etc.... From tab ......etc...
Isso porque o select precisará identificar cada campo existente na tabela antes de selecioná-lo. Assim a segunda opção, apesar de mais trabalhosa e deixar seu código mais extenso, será executada mais rapidamente e evitará esse problema que citou. Pois se ocorrer o erro será já no Select e não dentro do recordset, uma vez que teria de usar a variável sAcao em cada campo que fosse usar, deixando inviável.
2- Outra pratica é sempre sempre que implementar um campo na tabela, fazer o ajuste no código. Pois não dá para entender como pode ter no código:
Msgbox ControleData.RecordSet!CampoNome
Mas o campo não existir na tabela. Isso é o mesmo que incluir uma nova OCX no projeto e não distribuir no instalador.
Há várias regras e práticas em informática para evitar problemas como esse, e principalmetne para otimizar código com classes e funções, além de melhorar o desempenho ex:
Abrir e fechar o banco a cada acesso
destruir todos os objetos quando fechar um form ou o sistema
declarar e inicializar as variaveis corretamente, ex:
Ola Luiz Herrera,
Acredito que nao tenha explicado corretamente minha duvida,
vou tentar posta um exemplo de codigo para que fique mais objetivo,
mas qualquer um pode simular o codigo. o objetivo é ler um campo que ainda nao existe no Access.
Eu uso tratamento de erro em todas as rotinas que acessam o banco de dados
o problema é que quando o VB6 informa o erro 3265, ele PARA antes do erro para informar [ô]i[ô]Item não encontrado na nesta coleção[ô] . mas nao dá uma pista de qual o nome do campo que ele nao conseguiu mostrar o seu conteudo.
Este problema independe de consulata SQL, OCX etc.
Acredito que nao tenha explicado corretamente minha duvida,
vou tentar posta um exemplo de codigo para que fique mais objetivo,
mas qualquer um pode simular o codigo. o objetivo é ler um campo que ainda nao existe no Access.
Eu uso tratamento de erro em todas as rotinas que acessam o banco de dados
o problema é que quando o VB6 informa o erro 3265, ele PARA antes do erro para informar [ô]i[ô]Item não encontrado na nesta coleção[ô] . mas nao dá uma pista de qual o nome do campo que ele nao conseguiu mostrar o seu conteudo.
Este problema independe de consulata SQL, OCX etc.
preste mais atenção, suponhamos que eu possua uma tabela com os seguintes campos
id
nome
endereco
bairro
até ai tudo bem eu seia tabela que eu possuo, se eu fizer assim
Msgbox ControleData.RecordSet!Nome
não vai ocorrer um erro, porque o campo nome existe na tabela
porém se eu fizer assim
Msgbox ControleData.RecordSet!Cidade
ai vai ocorrer o erro 3265, porque este campo não existe em minha tabela
então pela lógica o campo [txt-color=#0000f0]Cidade[/txt-color] é o campo que não existe!
por fim, se o campo que vc mesmo solicitou não existir então ELE MESMO é O CAMPO QUE NÃO EXISTE.
id
nome
endereco
bairro
até ai tudo bem eu seia tabela que eu possuo, se eu fizer assim
Msgbox ControleData.RecordSet!Nome
não vai ocorrer um erro, porque o campo nome existe na tabela
porém se eu fizer assim
Msgbox ControleData.RecordSet!Cidade
ai vai ocorrer o erro 3265, porque este campo não existe em minha tabela
então pela lógica o campo [txt-color=#0000f0]Cidade[/txt-color] é o campo que não existe!
por fim, se o campo que vc mesmo solicitou não existir então ELE MESMO é O CAMPO QUE NÃO EXISTE.
Veja este exemplo de um codigo simples, em que os text box sao preenchidos com o conteudo de uma tabela logo ao carregar o formulário:
Private Sub Form_Load()
On Error GoTo Trata_Erro
[ô]----------------------------------------------------------------------------------
DataCliente.DatabaseName = App.Path & [Ô]/Bd Clientes[Ô]
DataCliente.RecordSource = [Ô]TabelaClientes[Ô]
DataCliente.Refresh
[ô]----------------------------------------------------------------------------------
Txt(0).Text = DataCliente.Recordset!Nome [ô]NOME
Txt(1).Text = DataCliente.Recordset!Endereco [ô]ENDEREÇO
Txt(2).Text = DataCliente.Recordset!Complemento [ô]COMPLEMENTO
Txt(3).Text = DataCliente.Recordset!Bairro [ô]BAIRRO
Txt(4).Text = DataCliente.Recordset!Cidade [ô]CIDADE
Txt(5).Text = DataCliente.Recordset!Estado [ô]ESTADO
Txt(6).Text = DataCliente.Recordset!Cep [ô]CEP
[ô]Txt(7).Text = DataCliente.Recordset!Telefone [ô]TELEFONE
[ô]----------------------------------------------------------------------------------
Exit Sub
Trata_Erro:
MsgBox [Ô]OCORREU UM ERRO AO CARREGAR ESTA TELA[Ô] & vbCrLf & _
Err.Number & [Ô] [Ô] & Err.Description & [Ô] [Ô] & Err.Source, vbCritical
End Sub
=========================================
Este codigo está totalmente funcional, agora suponhamos que eu tente apresentar o conteduo de um campo que ainda não existe nesta tabela
Txt(7).Text = DataCliente.Recordset!Telefone [ô]TELEFONE
Neste caso o tratamento de erro irá interceptar o erro e apresentará o ERRO 3265, mas só que não informa o nome do campo
Neste exemplo é obvio que o campo ausente é o [ô]Telefone[ô], mas se fosse qualquer outro campo ausente a mensagem seria a mesma.
Em tempo de desenvolvimento, basta desativar o tratamento de Erro que eu fico sabem imediatamente qual o campo que está ausente,
Mas depois que é gerado o executável, nao descobri uma maneira segura em que o VB me retorne o nome do campo campo ausente.
Obs.
Li o artigo do Macoratti sobre tratamento de erro, e ele apresenta uma solução alternativa em que ele volta ao primórdios do Basic e numera as linhas. A meu entender esta maneira de codificar está ultrapassada. E imagine um codigo com centenas, milhares de linhas de codigo, seria impossivel numerar todas as linhas.
Quem quizer baixar este projeto simples ele está em anexo
Private Sub Form_Load()
On Error GoTo Trata_Erro
[ô]----------------------------------------------------------------------------------
DataCliente.DatabaseName = App.Path & [Ô]/Bd Clientes[Ô]
DataCliente.RecordSource = [Ô]TabelaClientes[Ô]
DataCliente.Refresh
[ô]----------------------------------------------------------------------------------
Txt(0).Text = DataCliente.Recordset!Nome [ô]NOME
Txt(1).Text = DataCliente.Recordset!Endereco [ô]ENDEREÇO
Txt(2).Text = DataCliente.Recordset!Complemento [ô]COMPLEMENTO
Txt(3).Text = DataCliente.Recordset!Bairro [ô]BAIRRO
Txt(4).Text = DataCliente.Recordset!Cidade [ô]CIDADE
Txt(5).Text = DataCliente.Recordset!Estado [ô]ESTADO
Txt(6).Text = DataCliente.Recordset!Cep [ô]CEP
[ô]Txt(7).Text = DataCliente.Recordset!Telefone [ô]TELEFONE
[ô]----------------------------------------------------------------------------------
Exit Sub
Trata_Erro:
MsgBox [Ô]OCORREU UM ERRO AO CARREGAR ESTA TELA[Ô] & vbCrLf & _
Err.Number & [Ô] [Ô] & Err.Description & [Ô] [Ô] & Err.Source, vbCritical
End Sub
=========================================
Este codigo está totalmente funcional, agora suponhamos que eu tente apresentar o conteduo de um campo que ainda não existe nesta tabela
Txt(7).Text = DataCliente.Recordset!Telefone [ô]TELEFONE
Neste caso o tratamento de erro irá interceptar o erro e apresentará o ERRO 3265, mas só que não informa o nome do campo
Neste exemplo é obvio que o campo ausente é o [ô]Telefone[ô], mas se fosse qualquer outro campo ausente a mensagem seria a mesma.
Em tempo de desenvolvimento, basta desativar o tratamento de Erro que eu fico sabem imediatamente qual o campo que está ausente,
Mas depois que é gerado o executável, nao descobri uma maneira segura em que o VB me retorne o nome do campo campo ausente.
Obs.
Li o artigo do Macoratti sobre tratamento de erro, e ele apresenta uma solução alternativa em que ele volta ao primórdios do Basic e numera as linhas. A meu entender esta maneira de codificar está ultrapassada. E imagine um codigo com centenas, milhares de linhas de codigo, seria impossivel numerar todas as linhas.
Quem quizer baixar este projeto simples ele está em anexo
Citação::
preste mais atenção, suponhamos que eu possua uma tabela com os seguintes campos
id
nome
endereco
bairro
até ai tudo bem eu seia tabela que eu possuo, se eu fizer assim
Msgbox ControleData.RecordSet!Nome
não vai ocorrer um erro, porque o campo nome existe na tabela
porém se eu fizer assim
Msgbox ControleData.RecordSet!Cidade
ai vai ocorrer o erro 3265, porque este campo não existe em minha tabela
então pela lógica o campo [txt-color=#0000f0]Cidade[/txt-color] é o campo que não existe!
por fim, se o campo que vc mesmo solicitou não existir então ELE MESMO é O CAMPO QUE NÃO EXISTE.
O nome do campo que não existe está sempre depois do sÃmbolo [Ô]![Ô]
Note que o Marcelo insiste nos nomes que estão após este sÃmbolo.
A não ser que CONTROLEDATA apresente o erro e não se direciona ao tratamento de erro, você poderá atribuir o valor do campo a uma variável auxiliar antes de utililiza-la no CONTROLEDATA. Neste caso o tratamento de erro vai funcionar.
O Marcelo deu um exemplo simples em que os conteudos do campos vao sendo exibidos aos poucos em um Msgbox
No meu caso são muito campos e nao são exibidos em Msgbox.
Eles tem que ser carregados no evento load do formulario.
Isto sem dizer que muitos dos campos não são strings, mas variaveis Booleans (Sim/Nao) que iram forçar o programa a tomar uma decisao dependendo do seu conteudo
Ou entao campos numericos embutidos que nao tem uma apresentação visual no formulario
O controle data intercepta o erro e direciona para o tratamento do o erro. o problema é que independente do nome do campo ausente, sempre retorna o erro 3265 e não dá uma pista do nome do camo que nao consegiu encontrar.
Sua sugestão é interessante de colocar o nome do campo em uma variavel auxiliar, eu já havia tentado isto, mas o controle data nao aceita;
Seria + - assim:
Dim NomedoCampo As String [ô] DECLARA A VARIAVEL
NomedoCampo = [Ô]Bairro[Ô] [ô] PREENCHE O CONTEUDO DA VARIAVEL
No momento de eu tentar ler o conteudo deste camopo deveria funcinar assim:
Txt(3).Text = DataCliente.Recordset!NomedoCampo
Só que ocorre o mesmo erro, nao porque o campo Bairro nao exista, mas porque eu atribui o seu nome a uma variavel e o nome dela nao existe no banco
Se quizer tentar baixe o projeto exemplo e veja por si só.
Quem sabe o que procura, entende quando encontra.
No meu caso são muito campos e nao são exibidos em Msgbox.
Eles tem que ser carregados no evento load do formulario.
Isto sem dizer que muitos dos campos não são strings, mas variaveis Booleans (Sim/Nao) que iram forçar o programa a tomar uma decisao dependendo do seu conteudo
Ou entao campos numericos embutidos que nao tem uma apresentação visual no formulario
O controle data intercepta o erro e direciona para o tratamento do o erro. o problema é que independente do nome do campo ausente, sempre retorna o erro 3265 e não dá uma pista do nome do camo que nao consegiu encontrar.
Sua sugestão é interessante de colocar o nome do campo em uma variavel auxiliar, eu já havia tentado isto, mas o controle data nao aceita;
Seria + - assim:
Dim NomedoCampo As String [ô] DECLARA A VARIAVEL
NomedoCampo = [Ô]Bairro[Ô] [ô] PREENCHE O CONTEUDO DA VARIAVEL
No momento de eu tentar ler o conteudo deste camopo deveria funcinar assim:
Txt(3).Text = DataCliente.Recordset!NomedoCampo
Só que ocorre o mesmo erro, nao porque o campo Bairro nao exista, mas porque eu atribui o seu nome a uma variavel e o nome dela nao existe no banco
Se quizer tentar baixe o projeto exemplo e veja por si só.
Quem sabe o que procura, entende quando encontra.
Tópico encerrado , respostas não são mais permitidas