Skip to main content
Question

Oracle Spatial reader unable to access metadata

  • July 30, 2025
  • 2 replies
  • 104 views
joey_geoloog
Contributor
Forum|alt.badge.img+9

FME Form (Workbench) 2024.1.2.1 (20240906 - Build 24624 - WIN64)

Oracle Spatial Database 19.27.0 (19c)

 

Hello!

When trying to read data in from an oracle spatial database, I receive the message that FME cannot query the metadata table. 

It's unclear to me which metadata table the reader is trying to use. This happens both with a FeatureReader and a SQLExecutor, the behaviour is the same. When switching logging to debug, there is no further logging of the query that is being executed.

2025-07-29 13:52:56|   0.3|  0.0|INFORM|ORACLE Reader: Executing SQL Statement `SELECT * FROM DINO_DBA.GDW_BLK_ARE_VW' to obtain features for feature type `'
2025-07-29 13:52:56|   0.3|  0.0|WARN  |Could not query Metadata table for dimension for geometry column 'GEOMETRY' of table '' -- geometry will be assumed to be 2D

The FME documentation I could find (FME Support Center: Adding metadata entries for Oracle spatial tables or views) hasn't been updated since 2015.1, and refers to MDSYS.SDO_GEOM_METADATA which is a table that doesn't exist (at least, not in the version of Oracle Spatial that we have installed), but this may also be a typo and in fact relate to MDSYS.SDO_GEOM_METADATA_TABLE which does exist.

Tables available in MDSYS schema when using Oracle Spatial 19.27.0 on Oracle 19c

The user I am connecting to the database can correctly view the metadata in ALL_SDO_GEOM_METADATA and has additionally been granted SELECT rights to MDSYS.SDO_GEOM_METADATA_TABLE. The error message still comes up.

User can select on ALL_SDO_GEOM_METADATA where the metadata exists
User can select on MDSYS.SDO_GEOM_METADATA_TABLE where the metadata also exists

From looking at the error message I have two thoughts;

  1. The error message appears to indicate that a table name isn't being provided?
    table appears to be just two single quotes
    Changing the SQL statement between referencing SCHEMA.TABLE or just TABLE still doesn't change the result. 
    [..] geometry column 'GEOMETRY' of table '' [..]

     

  2. The other possibility was that the readers erroneously only look in USER_SDO_GEOM_METADATA, which in this case won't return any results as the user I am logged in as is not the owner of the spatial tables.

User's own USER_SDO_GEOM_METADATA table is empty for this TABLE_NAME as it is in a different schema

I have a feeling it's either a bug, or it's a case of oversight as to where the metadata is being read in from. I'd really appreciate any input you can give on this!

sean1spatial

2 replies

steveatsafe
Safer
Forum|alt.badge.img+13
  • steveatsafeSafer
  • Safer
  • October 18, 2025

Hi ​@joey_geoloog, Thanks for filing the ticket and posting this question.

 

Since the message is a WARN and not an ERROR it can be ignored I think in this case.  However, we will indeed file an issue to understand why this is happening and improve the logging.  

As you pointed out, the documentation, in this case an article, is out of date and we’ll get that sorted… 

I have tested this in 2024.2 and I see the same error message even though I know the metadata is correct.  I also tested creating a new table and the metadata and spatial index were both created correctly.  The metadata is living in ALL_SDO_GEOM_METADATA as the user that created the table.

So I have a few questions for you:

  1. Are you seeing evidence that a spatial query is not using a spatial index and performance is really bad?
  2. Is there a difference between running the same query in SQLCreator as the schema owner vs another user? 
  3. Is there a difference in the performance of the FeatureReader with schema owner and non owner running a spatial query?

In my testing, which I could only do quickly with SQLCreator, I could see it using the spatial index in both cases (owner and non-owner).  I did this by reviewing the query plan.

I wasn’t able to dig into the FeatureReader in the same way but I could if this is where the issue is - performance. 

I know it is confusing when the log file spits out a WARN message like this so I apologize for that.  

Again, thanks for bringing this up with us.  Very much appreciated!

SteveatSafe
j.botterill
joey_geoloog
Contributor
Forum|alt.badge.img+9
  • joey_geoloogContributor
  • Author
  • Contributor
  • October 20, 2025

Hi ​@steveatsafe 

Thanks for your reply!

After discussing this further with our intermediary (Vicrea) we opened a ticket with you guys directly, that is #57614.

To answer your questions;

In regards of performance, I have no metrics but indeed this has been started as a result of performance problems. I can put some time into collecting actual metrics if that helps?

Indeed we do see a difference between SQLCreator (metadata error), SQLExecutor (no error), and FeatureReader (metadata error). This has been provided in more detail in the ticket, but the behaviour doesn't match across all three readers.

Let me know if I can elaborate any further

Joey

More info is in this feature request:
FeatureReader / Oracle Spatial should evaluate ALL_SDO_GEOM_METADATA as fallback | Community

 

 

Community Stats

32,127
Posts
121,960
Replies
39,777
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.