Skip site navigation (1) Skip section navigation (2)

Fw: PgOleDb / PostGis / PostgreSql interface problem

From: "Clay, Bruce" <bclay(at)ball(dot)com>
To: <pgsql-interfaces(at)postgresql(dot)org>
Subject: Fw: PgOleDb / PostGis / PostgreSql interface problem
Date: 2005-05-27 15:58:10
Message-ID: C482FF98AE985A47B8C982FD429C9E344F25DC@daytonmsg2k3.AERO.BALL.COM (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
The following is a message is one I originally posted on the pgFoundary
list.  At the bottom of the note is a reply from Shachar Shemesh.  I am
cross posting it here because there seems to be some concern as to where
the issue originates.


If anyone has any suggestions I would be happy to experiment to find a
valid solution.


The gist of what I am trying to do is use PostgreSql as a geospatial
database server that can be accessed though a WEB page, a WEB service,
ArcMap or any other application that I am called on to write.  If this
is not the right combination of libraries, please let me know.  If this
is not the right forum for this question, plaee let me know where I
should post this.  It seems like it is an interface issue that is why I
am posting it here.


Thank you for your help.




Clay, Bruce wrote:
> I am getting the same message that Uwe Seher mentioned back on 11 May.
> I am using a combination of PostgreSql 8.0.3, postgis (version 
> provided in the PostgreSql 8.0.3 installer) and what I believe to be 
> the current PgOleDb dll.
> I have loaded a few databases in PostgreSql and I can see the table 
> names in ArcCatalog after I make an OLE DB connection.
> Two problems show up but I can not say at which level of the process 
> they occur.
> The first is as the title says one that says:
> Failed to edit the selected object(s)
> General Function failure
> ERROR: no binary output function available for type geometry
> Fatal error in query.
> The standard tables used by template1 all seem to open ok but the 
> table that has the actual data fails with the above error message
I'll offer you a deal. You forward the message I tried to send to the 
postgis mailing list and couldn't (I'm not subscribed, and I don't have 
the bandwidth to subscribe to yet another mailing list), and to carry 
out the discussion on my behalf there, and I'll try to solve this one,
> The second problem I encountered seems to be one of case sensitivity. 
> If a table has uppercase letters such as VE_SubProv I get the 
> following error message
> Failed to edit the selected object(s)
> General Function failure
> ERROR: relation "public.ve_subprov" does not exist.
> Fatal error on query
What usage type? What commands were you using?
Please forward the following email to the postgis list.
> Hi all,
> Please include me in the CC of all replies, as I'm not subscribed to 
> the list.
> I am the maintainer of PgOleDb (, 
> the OLE DB provider for PostgreSQL. This driver is beginning to 
> mature, and we are starting to get questions on the PgOleDb list about

> PostGIS support. As I know nothing about it, I'm asking here.
> Personally, I don't really care one way or the other, so if anyone 
> here wants PostGIS support in PgOleDb, you will have to do at least 
> some of the work. Most important is giving a concise list of all data 
> types that PostGIS adds to PG, and how Windows program typically 
> expect to receive them (when expecting binary returns). If a 
> translation is required between the way PG usually exports it, and the

> way OLE DB is expected to return it, small code doing the actual 
> translation would be GREATLY appreciated (PgOleDb is under the LGPL, 
> so whatever code you provide must be under a LGPL compatible license).
> More worrying, I have a question on the list 
> which suggest that some of the GIS types don't have binary exports 
> functions. This is a bug in the type, and PgOleDb cannot be expected 
> to solve it. Like I said above, I am not a GIS user myself, and I 
> therefor don't know anything about it. I tried to find the SQL 
> instructions for installing support for the GIS type, and couldn't 
> even locate them (I seem to need to grab lwpostgis.sql from somewhere,

> but it doesn't seem to be in neither PostGIS nor PostgreSQL source 
> distributions).
> Shachar
Shachar Shemesh

Lingnu Open Source Consulting ltd

pgsql-interfaces by date

Next:From: Volkan YAZICIDate: 2005-05-28 20:34:20
Subject: libpq, blocking/nonblocking mechanism
Previous:From: Gustavo LopesDate: 2005-05-22 17:48:13
Subject: Re: libpq on windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group