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 1pPY3C-00036f-EW for pgsql-general@arkaria.postgresql.org; Wed, 08 Feb 2023 00:11:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pPY3A-0006g2-2M for pgsql-general@arkaria.postgresql.org; Wed, 08 Feb 2023 00:11:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pPY39-0006fr-LR for pgsql-general@lists.postgresql.org; Wed, 08 Feb 2023 00:10:59 +0000 Received: from mail-yw1-x112e.google.com ([2607:f8b0:4864:20::112e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pPY36-0008F0-KY for pgsql-general@lists.postgresql.org; Wed, 08 Feb 2023 00:10:58 +0000 Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-4b718cab0e4so215575117b3.9 for ; Tue, 07 Feb 2023 16:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CUvqjYZt6NCp1lkARmT/jjh/aLSYtmcI3vr+oPsRmYU=; b=iq5Llcq/QFAWDx0PFPZk36ZW5hOx5jVrpkgoqsVYB7pTcMaSmNfJ/VsumMUzWwc4t5 CshJK2tC8I4FWGFfCiBcRE/e2eOypQnBb1n+3fbxqi4mjEFCkJESUdl6E6DbvmLzNDPv EhYMIJ1MZDAI82rJbB80KGCq7WzrCjSghwknZPMNQQ722JAluu6AtxHjHZEVB69mFNY7 aJXVHFceLoxb+4ja9n5lFciJPRVnh/h4nIcllaZ8WL8WLiJHj7K8o0Qsp9TKVG8n3YoJ 2WM4hNvpXN6l/2GX9pZV0+XcPfLWJn+JBQ9hy2ejXzmx/v7yvNZEaru6tAReMIt/ZVRA SY9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CUvqjYZt6NCp1lkARmT/jjh/aLSYtmcI3vr+oPsRmYU=; b=bwh9eGZieoH+JSTSh2PhY3j4Roo9MnCskpzHrkWrsMF/0LXi0d+QpPplqcrbw+r4Da 0GRbZIUvYmkNylpaXh7HmwR7RZphCIi6RI54kOA1xUGmO6AtunST9hRjhaiXXBgalJqn Ku5rkrXHdaT3GqWSpM6smC82ackO5d5hlTRndXaUzDFQlS1eDBG5dDoL8ZV2qlA/qDZj 88THG6k9U5QNlvGhwqtnEh/GpQMnp0JWbdOmFj0Zz2XXMLtkPHEtHNU7+1515vY6pL/7 vpS9GmP9ynsTrPNBFmlc/2BQ3f1BcdA/uBO8/UoQLHMr2plNJE4e64NJ73MNt+JGjYHa QVVQ== X-Gm-Message-State: AO0yUKUkUJJR5v0+BbdQ13QuK7LE4zJCvIVsP0arGD+6ZMTspNiakIDx Wtf0GN2ppbj249gVybTu/WORJWJd61gI8yqDrs6Nt4GGlsk= X-Google-Smtp-Source: AK7set8Y/XBPyR6du0zweT+pAVhrsoLyEuv3v8q7UJgs2SZanGEgLS8ZZmEKSNt8g+2ZEpiBQKVl5GtuckrL6Vv521s= X-Received: by 2002:a81:7243:0:b0:527:9c7a:3493 with SMTP id n64-20020a817243000000b005279c7a3493mr675237ywc.373.1675815055614; Tue, 07 Feb 2023 16:10:55 -0800 (PST) MIME-Version: 1.0 From: Brad White Date: Tue, 7 Feb 2023 18:10:44 -0600 Message-ID: Subject: Quoting issue from ODBC To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000019685405f42519a8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000019685405f42519a8 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 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. 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. --00000000000019685405f42519a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Front end: Access 365
Back end: Postgres 9.4
(I= know, we are in the process of upgrading)

I&#= 39;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 Ac= cess usually does a better job at converting the queries than I would have = expected, but not in this instance.

For example

Access:=C2=A0connection.Execute "UPDATE ["= & strTable & "] SET [" & strTable & "].[Ins= ertFlag] =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=A0UPDA= TE "public"."Orders" SET InsertFlag=3DNULL =C2=A0WHERE = ("InsertFlag" =3D 166 )
Note that InsertFlag is quoted = once but not the other time.
Of course this gives the error: colu= mn "insertflag" of relation "Orders" does not exist at = character 35.

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

Any suggest= ions on where to look?

Thanks,
Brad.
--00000000000019685405f42519a8--