Only a few tables are visible through Oracle import

K; 

I believe you are real close.

 

Here are the requirements for the SelectSeries1 version.

 

In order for an Oracle table to be recognized as a feature, the following criteria must also be met:

• The feature table must have a primary key constraint consisting of a single numeric or string/character column to represent the feature ID. This primary key is required to enable versioning using the standard versioning system of the Oracle Workspace Manager.
• The table must have a geometric (SDO_GEOMETRY) column specifying the feature geometry, and this geometry column must be registered in the Oracle Spatial metadata table (ALL_SDO_GEOM_METADATA or the related USER_SDO_GEOM_METADATA view for the user).
• The table fields must be of a common type, not a user defined type.
• Geometry must be of similar types, meaning all geometries must be of point, line, or polygon type, not a mixture of these.

 

HTH

Jerry

Hi, So this is true even if I only want to read the data? In good old GeoGraphics (and SpatialViewer) I could read data from any table as long as I didn't need to post it back to Oracle. If this is the case this is a major problem for me, I and guess lots of others. Bentley Map shouldn't restrict my data model, it should adapt to it. Regards, Krister

The note...... 

"primary key is required to enable versioning using the standard versioning system of the Oracle Workspace Manager."

is probably confusing you a bit. 

If you do not version the tables in Oracle spatial, then the assumption is you are not going to post edits back, and thus the feature instances are read only. Placing a table into a versioned state assumes that the data is going to be edited. This comes form the Oracle side, and Bentley Map is honoring that design. Thus the note in the requirements concerning the primary key and versioned tables. If you have versioned a table, you need the primary key to keep track of the versioning information. We are just saying that this key needs to be a simple primary key.

 

HTH

Jerry

The note...... 

"primary key is required to enable versioning using the standard versioning system of the Oracle Workspace Manager."

is probably confusing you a bit. 

If you do not version the tables in Oracle spatial, then the assumption is you are not going to post edits back, and thus the feature instances are read only. Placing a table into a versioned state assumes that the data is going to be edited. This comes form the Oracle side, and Bentley Map is honoring that design. Thus the note in the requirements concerning the primary key and versioned tables. If you have versioned a table, you need the primary key to keep track of the versioning information. We are just saying that this key needs to be a simple primary key.

 

HTH

Jerry

Yes I'm confused, and probably need to catch up on Oracle versioning. However, our customer (and us) have used Oracle Spatial 10g for quite some time and never needed to bother about that issue before. Both MicroStation GeoGraphics, GeoMedia and other clients can access all our tables, both with simple keys and compound keys. Bentley Map is the first software we use that has this problem. "We are just saying that this key needs to be a simple primary key." This is the main problem. A lot of users have data models using compound primary key. Regards, Krister Surell

Hi again,

I would really like to know if anyone has a solution to this problem. It can't be that Bentley Map cannot read/display spatial tables with compound primary keys.

Regards,

Krister Surell

Hi Kirster. Bentley Map effectively does not support compound primary keys at the moment for registered features or ad-hoc Oracle connections. However, you can still read your data using the Interoperability dialog. You can add an "import" entry and choose the "Add Oracle (read-only)" option. This should list your missing tables.

Hope this helps,

   Martin

Hi Martin,

Thank you for clearing out the difference. Beeing quite new to Bentley Map I just tried the "Open Oracle Spatial" option. The Interoperability dialog works just fine.

Still looking forward to be able to do updates in the future though. Could that be done by creating updatable views with a single, derivated, key?

Regards,

Krister