2

We have a problem to integrate GIS software with our GIS database which is populated on Postgres Plus Advanced Server 9.2 from EnterpriseDB. We are using QGIS to maintain and analyze our GIS repository, the software is working just fine when the database in the postgres community version, but when the database in ppas; QGIS return the following error while trying to fetch the list of GIS layers:

Erroneous query:

 SELECT l.f_table_name,l.f_table_schema,l.f_geometry_column,upper(l.type),l.srid,c.relkind 
 FROM geometry_columns l,pg_class c,pg_namespace n 
 WHERE c.relname=l.f_table_name 
   AND l.f_table_schema=n.nspname 
   AND n.oid=c.relnamespace 
   AND has_schema_privilege(n.nspname,'usage') 
   AND has_table_privilege('"'||n.nspname||'"."'||c.relname||'"','select')
 ORDER BY n.nspname,c.relname,l.f_geometry_column

returned 7 [ERROR: schema "dbms_profiler" does not exist]

And the following is the answer from EnterpriseDB:

We looked at query and it seems, issue is the way that query built. By default, PPAS stores package names in namespace table and so it is retrieving the names of packages as name of schemas hence query is failing. It works in PostgreSQL. Though, you are in postgres compatibility, we still retains some packages.

So we would recommend you to contact QGIS vendor on the same as it is not tested with PPAS.

closed as off-topic by PolyGeo Jul 3 at 20:43

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions that relate to the business of vendors and product teams, such as licensing, pricing, release dates, submission of bug reports and enhancement requests, etc, are off-topic here and should be directed instead to the official software support teams." – PolyGeo
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Looks like EnterpriseDB is telling you that QGIS is not compatible with their product, and they don't care to fix it. I'd get a better database vendor... – BradHards May 25 '14 at 10:08
  • Do you really need PPAS? What relationship does it have to your spatial data? – Michael Stimson May 25 '14 at 10:16
  • PPAS is usually selected because of the interoperability it offers for administrating both Oracle and PostgreSQL. The decision to start using PPAS is probably well thought. In this case I would consider if it would be possible to run a standard PostreSQL+PostGIS for spatial data but system admins fore sure would not like the idea very much. – user30184 May 25 '14 at 10:27
  • I have encountered similar problems before: one database on one server for all systems. This is an ideal I.T. standpoint as it's only one system to administer but it doesn't always work that way, sometimes applications need an environment that doesn't suit the other players - which appears to be the case here. On the bright side PostgreSQL is free, in the previous cases it was Oracle and SQL Server Enterprise which are definitely not free. For just the cost of hardware (and O.S. if not Linux) you could separate the data and copy required tables between servers as needed. – Michael Stimson May 25 '14 at 10:49
  • 3
    It can also be that it would not require huge changes to QGIS PostGIS provider for making a new Enterprise DB provider. In the few tests I have made with GDAL it had no troubles with Enterprise DB so this problem may deal only with where and what metadata QGIS wants to read. Some funding would probably be needed, though. Contact QGIS developers. – user30184 May 25 '14 at 11:25