Received: from approximator.webwork.co.uk ([195.188.128.3]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f64HBRa79030 for ; Wed, 4 Jul 2001 13:11:28 -0400 (EDT) (envelope-from techsupport@ntb.org.uk) Received: from wslibretto (dhcp39.north-east.co.uk [195.188.128.39]) by approximator.webwork.co.uk (Postfix) with SMTP id 7B74911B1 for ; Wed, 4 Jul 2001 18:09:14 +0100 (BST) Message-ID: <00b801c104ac$c578d140$2780bcc3@northeast.co.uk> From: "NTB Technical Support" To: Subject: ADO and ODBC Date: Wed, 4 Jul 2001 18:14:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Archive-Number: 200107/25 X-Sequence-Number: 1778 We're trying to migrate some Access databases which have a substantial number of table row- and column names which contain spaces - and then use them via ADO/ODBC from Microsoft IIS. The problem seems to be that if we use the ADO interfaces to update the contents of a recordset retrieved from postgresql, an ODBC parse error is generated at the point of issuing the RS.UPDATE if the table name and/or ANY column name in the table contains a space. I assume that ADO is, behind the scenes, generating an SQL Update for every column in the row and something (ADO or the postgresql ODBC driver) isn't correctly quoting/escaping the table and column names that result. Is there any way to work round this, short of going through several thousand lines of ASP and changing the name of every table and column that is referenced?? Tim Dixon NTB Tech Support