Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XPDUj-0000J0-PT for pgsql-admin@arkaria.postgresql.org; Wed, 03 Sep 2014 16:33:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XPDUj-0002gN-42 for pgsql-admin@arkaria.postgresql.org; Wed, 03 Sep 2014 16:33:17 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XPDUh-0002g6-KH for pgsql-admin@postgresql.org; Wed, 03 Sep 2014 16:33:16 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XPDUe-0005w3-4W for pgsql-admin@postgresql.org; Wed, 03 Sep 2014 16:33:13 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 6D24920B89 for ; Wed, 3 Sep 2014 12:33:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 03 Sep 2014 12:33:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=fNWecYXSmVjjQxBjJ7r89jmkYZ0=; b=PMOv7XWPZZSZVv5kZFWHA4iMB27D cF4R8dJoV4J13w+C3exYDUgX5CjgVqqEf4OXAbtXNhb6GYW6qUlBRRsK9eywkQEv 533hFCTfQQtcABJWAe8FwSZbj41EQY8VCNgWGqLm4i9bqz4vH+Way/mznoYM7cOS DPjyH5uMc5a/tUw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=fNWecYXSmVjjQxBjJ7r89j mkYZ0=; b=hoCak5sgX6e3uKtPhgGLYqYqppr8vgazouHQVGfmEhO9x3b/w0zjG8 xwnoi0RBxXVERAy1gb8vTEuCTiGhkJoWokgV7SEFxyvQlfHWm6+/iyk6a4yoX/qD qpkyg4wU5UDN04gig8hlhImApnXhZDNTInKq90ns0Y2r9+vRyPBUg= X-Sasl-enc: E6EkefxGYepqTBesc8it8/FQRVuPkBMD1WlSin/TykQb 1409761987 Received: from killi.site (unknown [173.160.167.74]) by mail.messagingengine.com (Postfix) with ESMTPA id BD8B6C0091D; Wed, 3 Sep 2014 12:33:06 -0400 (EDT) Message-ID: <540742C1.50106@aklaver.com> Date: Wed, 03 Sep 2014 09:33:05 -0700 From: Adrian Klaver User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Craig James , Alanoly Andrews CC: "pgsql-admin@postgresql.org" , "pgsql-general@postgresql.org" Subject: Re: [GENERAL] Re: Cannot retrieve images inserted through VB and odbc, after a table reorganization. References: <6909b219ecae4d41b431efdaf6c953a3@Exch2.invera.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org On 09/03/2014 09:12 AM, Craig James wrote: > > On Wed, Sep 3, 2014 at 8:13 AM, Alanoly Andrews > wrote: > > *We have an issue with images (**TIFF files) that are loaded into a > postgres database table (where the image field is defined as type > **“**lo**”**)**. The code to load the images is written in VB and > the connection to the database is through postgres odbc**installed > on the PC. ****All images inserted through the VB program are > retrievable also through odbc/VB, as long as the table **rows **at > the backend **are**not re**organized in any way. If the table > dat**a**is unloaded/reloaded or clustered (on an index) or > rel**oaded through a pg_dump and restore, then **on trying to > retrieve the images, **the VB program gets the error : > **“**Multiple-step OLE DB operation generat**ed errors. Check each > OLE DB status value**……**etc**”**.* > *The data in the backend database is still readable through other > image retrieval progr**ams connecting directly to the server (not > through ODBC or VB).* > > > Are you reloading into the very same database, or into a different one? > Your question doesn't make it clear. If you're loading into a new > database, then one thing that comes to mind is that the bytea_output > parameter in postgresql.conf might be different on the second database. The OP is using the lo type, so I suspect it is something to do with the OIDs changing. I do not use lo so I cannot really be more helpful. > > Craig -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin