Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pPYCZ-0003WY-Ny for pgsql-general@arkaria.postgresql.org; Wed, 08 Feb 2023 00:20:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pPYCY-0002ks-IY for pgsql-general@arkaria.postgresql.org; Wed, 08 Feb 2023 00:20:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pPYC7-0004m3-8n for pgsql-general@lists.postgresql.org; Wed, 08 Feb 2023 00:20:15 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pPYC1-0007Jb-AV for pgsql-general@postgresql.org; Wed, 08 Feb 2023 00:20:14 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-501c3a414acso216120157b3.7 for ; Tue, 07 Feb 2023 16:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=xjy8SLJGm2l9+2GyenF0kns7EhR3zSVbSc9RES57Ajc=; b=VzR8BeA79arAejOcX9r/A/rWEvxmGlOIZ/0/dB0v0q74cV2qI0UY7m0xav58ChRjQW gWFkfDw9fuoYryi5ZxRxcF2BAG4Dt6C8ZPZ12aJ+5wlFCgzN6wX8l56zwQEAr/QMcGTS UqNb6G1wpeHUY6uVNrm3PGUlyRwz8BWXsDaz6LZI4yvqOkiOzZZENMg8/owMX3DO9Frn D80KX8p4MN2pcOzHgwlKlQKaOG6ynpnUITLPzbtmU8kANU31XCJ2MYxmD3ZoWXtJLbme smeUL13c3eZsMaghAMBLCfv5V60g3rFOzJer19HAB7GI/yIuFrtiSl9Xsi0Vm6VEMAgr UuGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xjy8SLJGm2l9+2GyenF0kns7EhR3zSVbSc9RES57Ajc=; b=asjPkueg2xcGvdVaD9ES85WSmz7CvcHl99+ypQFtVfUriQyQ+QPIC86yBwh2Hx6Et2 nIlgT0+2pkb2d+rxsFNFQ28UOAZdlsxjobb/FDdjR7Bg38hYKlqlYYHKKRW0WLA5YJ3a Y30DFp68zTj2Z7Rm4UI6GVRGjTFCXjQExeJyKlmxFskF/wazWltsGwXPBhUmIMpl+pb6 9HWnSxmAoNvrbFTtDvAZw+AfV/AzxgXy6l+4k26oiw0eOYP5FsQehiRJC6sH4Z8WQJPL 6emK+sk/lQrqUlgYaZeA8b2GMBHb4ABJBvDCVDzU4pJP8/JiFuFGBD3NMSuD686AL3vL QQiA== X-Gm-Message-State: AO0yUKX0uMqoKUfyWznUN8Ou4PASncsVYhgtEaipGz5fR3XwM7FaKYrK OjcdtnR0Jdc+3pyOzEOKnL2gjCi148N5oi57ZTf6Inh1 X-Google-Smtp-Source: AK7set/47/87DQk/ynhuNSlTT55g6ScmTCukFAfVX7Ar4vGbkGlxe/LEhpu9nROzcdM/qZXCkrE7ndLUN2lms9DlMVw= X-Received: by 2002:a0d:f946:0:b0:507:9f0e:c75e with SMTP id j67-20020a0df946000000b005079f0ec75emr676030ywf.69.1675815607379; Tue, 07 Feb 2023 16:20:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brad White Date: Tue, 7 Feb 2023 18:19:56 -0600 Message-ID: Subject: Fwd: Quoting issue from ODBC To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000fcadf805f425397d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fcadf805f425397d Content-Type: text/plain; charset="UTF-8" Front end: Access 365 Back end: Postgres 9.4 (I know, we are in the process of upgrading) I'm getting some cases where the SQL sent from MS-Access is failing. Looking at the postgres log shows that the field names and table names are not being quoted properly. It has been my experience that Access usually does a better job at converting the queries than I would have expected, but not in this instance. For example, this is the literal code in VBA Access: connection.Execute "UPDATE [" & strTable & "] SET [" & strTable & "].[InsertFlag] = Null" _ & " WHERE ((([" & strTable & "].[InsertFlag])=" & lngCurrUID & "));", , adCmdText Or adExecuteNoRecords Note that InsertFlag is bracketed the same way in both instances. PSQL: UPDATE "public"."Orders" SET InsertFlag=NULL WHERE ("InsertFlag" = 166 ) Note that InsertFlag is quoted once but not the other time. Of course this gives the error: column "insertflag" of relation "Orders" does not exist at character 35. No ORM involved. Looks like I have about 16 unique instances of statements not being quoted correctly resulting in over 500 errors in the log for today. Any suggestions on where to look? Thanks, Brad. --000000000000fcadf805f425397d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Front end: Access 365
Back end: Postg= res 9.4
(I know, we are in the process of upgrading)

<= /div>
I'm getting some cases where the SQL sent from MS-Access is f= ailing.
Looking at the postgres log shows that the field names an= d table names are not being quoted properly.
It has been my exper= ience that Access usually does a better job at converting the queries than = I would have expected, but not in this instance.

F= or example, this is the literal code in VBA

Access= :=C2=A0connection.Execute "UPDATE [" & strTable & "]= SET [" & strTable & "].[InsertFlag] =3D Null" _=C2=A0 =C2=A0 & " WHERE ((([" & strTable & "].= [InsertFlag])=3D" & lngCurrUID & "));", , adCmdText = Or adExecuteNoRecords
Note that InsertFlag is bracketed the same way in= both instances.

PSQL:=C2=A0UPDATE "public"."O= rders" SET InsertFlag=3DNULL =C2=A0WHERE ("InsertFlag" =3D 1= 66 )
Note that InsertFlag is quoted once but not the other time.<= /div>
Of course this gives the error: column "insertflag" of = relation "Orders" does not exist at character 35.

<= /div>
No ORM involved.

Looks like I have=C2=A0about= 16 unique instances of statements not being quoted correctly resulting=C2= =A0in over 500 errors in the log for today.

Any suggestions on where to look?

Thanks,
Br= ad.
--000000000000fcadf805f425397d--