Início / coding / Perguntas / 79558000
Accepted
wannabeprogrammer
Asked: 2025-04-06 17:01:44 +0800 CST

Erros de instrução SQL ao usar ActiveX Data Objects (ADO) VBA no Microsoft Access

  • 772

Estou experimentando usar o ADO para conectar um frontend do Access a um backend do Access. O frontend é apenas uma ferramenta de entrada de dados. Os usuários não farão edições/atualizações em nenhum registro no backend. O motivo para fazer isso é que mais de 255 usuários usarão o frontend simultaneamente, então tabelas vinculadas normais com conexão persistente ao backend não funcionarão (sei que essa configuração parece ilógica; por favor, evite dizer que eu não deveria usar o Access para o backend).

Consegui fazer funcionar para algumas coisas. Uma Insertinstrução SQL curta funciona como esperado, mas uma Insertinstrução mais longa (11 colunas no meu caso) resulta em um erro:

Erro de tempo de execução '-2147217900 (80040e14)': erro de sintaxe na instrução INSERT INTO

Veja como o código se parece:

Public Const ConnectionStr As String = "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=\\[Network]\[Folder]\[File].accdb"
Dim conn As New ADODB.Connection, SQLstr as String

conn.Open ConnectionStr
SQLstr = "INSERT INTO [mytable](field1, field2, [...], field11) values(1, 2, [...], 11)"

Debug.Print SQLstr
conn.Execute SQLstr
conn.Close

Os valores na insertinstrução são todos obtidos de controles no frontend, então há muita concatenação de strings, mas esse não é o problema. Copiei a debug.printsaída da janela imediata, colei na janela de consulta do Access, executei e o registro foi inserido sem problemas.

(Eu também estava recebendo "erro de sintaxe na cláusula FROM" ao fazer uma consulta select com uma cláusula where, mas não consigo replicar isso agora)

Então, qual é o motivo desse erro e existe uma maneira de corrigi-lo? Existe um limite de tamanho de texto para strings SQL executadas com conexões ADO? Acho que isso não faria sentido... Mas testei reduzir o número de campos na instrução insert para 9 e funcionou.

Minha solução alternativa é apenas usar o DAO, criando uma tabela vinculada temporária ao backend, executando a insertinstrução e, em seguida, excluindo a tabela vinculada

Imagem adicionada em resposta à resposta de Jonathan abaixo: captura de tela do VBE

sql

2 respostas

  1. Best Answer

    Languageé uma palavra reservada

    Seu SQL é executado sem erros quando você o cola no designer de consultas porque ele usa DAO, e o DAO é mais tolerante a palavras reservadas.

    Mas o ADO tem maior probabilidade de engasgar com palavras reservadas. Um exemplo frequente é nomear uma coluna Password. Se você testar esse nome, verá o mesmo padrão que está vendo com Language: erro de sintaxe com ADO; nenhum erro com DAO.

    • 2

  2. Você certamente pode inserir mais de dez campos de uma só vez. Portanto, tenho quase certeza de que o seu problema está nos dados que você está inserindo. Para facilitar sua vida, em vez de gerar uma string longa, recomendo fortemente que você passe a usar um objeto de comando com parâmetros. Seu código ficaria mais ou menos assim:

    Dim conn As New ADODB.Connection, SQLstr As String, cmd As New ADODB.Command, bigtext As String
bigtext = "I am experimenting with using ADO to connect an Access frontend to an Access backend. Frontend is just a data entry tool. Users wont be making edits/updates to any records in the backend. Reason for doing it this way is because more than 255 users will be using the frontend concurrently, so normal linked tables with persistent connection to the backend will not work."
conn.Open ConnectionStr
SQLstr = "INSERT INTO test(ID, Description, DOB, LongDescription1, LongDescription2, ... LongDescription11) values(@id, @desc, @dob, @ld1, @ld2, ... @ld11)"
cmd.CommandText = SQLstr
cmd.CommandType = adCmdText
cmd.Parameters.Append cmd.CreateParameter("@id", adInteger, adParamInput, , 5)
cmd.Parameters.Append cmd.CreateParameter("@desc", adVarChar, adParamInput, 20, "test5")
cmd.Parameters.Append cmd.CreateParameter("@dob", adDate, adParamInput, , #1/1/2025#)
cmd.Parameters.Append cmd.CreateParameter("@ld1", adVarChar, adParamInput, 500, bigtext)
cmd.Parameters.Append cmd.CreateParameter("@ld2", adVarChar, adParamInput, 500, bigtext)
...
cmd.Parameters.Append cmd.CreateParameter("@ld11", adVarChar, adParamInput, 500, bigtext)
cmd.ActiveConnection = conn
cmd.Execute
conn.Close

    O uso de parâmetros tem a vantagem de proteger contra injeção de SQL, mas, no seu caso, torna muito mais fácil identificar qual campo está causando o problema. Além das palavras-chave (como sugerido por @Storax), o problema também pode estar sendo causado por caracteres especiais. Se você usar parâmetros, será muito mais fácil comentar alguns e isolar os que estão causando o problema.

    Dei um exemplo de diferentes tipos de parâmetros. Obviamente, existem mais, mas deve ser fácil descobrir o que você precisa.

    • 1

relate perguntas