Troubleshooting

Use this table to help resolve issues.

Issue AreaProblemSolution
Char data typesQuerying on a foreign vault with a specified revision returns no objects even though it should. The revision field for the foreign object is probably mapped to a column in Oracle that contains the char data type. This type of data must consistently contain the same number of characters. For example, if the data column is set to a width of 10 but only contains 1 character (for example, the number 1), Oracle adds 9 spaces for padding. To find the object correctly the revision identifier must include a * wildcard after the character (1*) (or type "1" with 9 spaces after it.) For example, to find PART 10000000A 1, the user has to do a find for:
PART
10000000A 
1*

or

PART 10000000A 
1 (and 9 spaces)
;  

If you change the Oracle data to either varchar or varchar2 datatype, the problem will be resolved.

Changing object namesWhen the name and ID for a type map to the same column, changing the name of an object also changes the ID. This causes the object in the 3DSpace browser to become “stale” and it appears to lose its attribute values and all relationships. Re-do the query to refresh the object, and notice that attribute values and relationships are now correct.
Multiple column primary keysReceived error:
ORA-01438: value larger than specified precision allows for this column

when attempting to connect two objects with a relationship that is mapped with multiple columns as the primary ID.

There are multiple columns specified as the relationship ID, and they are defined with different column sizes in the relational database. When IDs are defined using multiple columns, all columns must be greater than or equal to the size of the first column specified in the id. For example, in the type definition below, the component column must be larger than the supplier column:
type {
     id Vendors(SUPPLER,COMPONENT) mapped;
     ...
}
Creating an INITIAL extent for vaultsReceived error:
Can’t create new vault
ORA-01658: unable to create INITIAL extent for segment in tablespace ADAPLET

when creating a foreign vault for an adaplet to connect 3DSpace to a foreign Oracle application.

The data file associated with the adaplet’s table space does not have enough space. Increase the size of the data file for the table space before creating the foreign vault.
Disconnect relationships and “Not Null Column” optionThe disconnect relationship between adaplet objects with the "not null column for id" option fails when the first column in the id statement is the same as the first column in the from statement.Use the delete clause to disconnect the relationship. For more information, see the row for delete OPTION in Mapping File Syntax.
Business objects with multiple column primary keysThere is a problem in the way 3DSpace records information in the lxforeign table for a business object whose type definition contains a multiple column primary key. Adding or modifying such business objects will not work.Add an object in a foreign database or move an object to the foreign database (for example, using the modify bus command) without specifying attributes. Then perform a print bus command to correctly generate the lxforeign table entry. After this completes successfully, specify the attribute values using another modify bus command. This ensures that the cross-reference entry in the lxforeign table correctly contains the information for the foreign object. Then you can modify the foreign object.
Querying a foreign vault through a 3DSpace ServerWhen attempting to query a foreign vault, receive the following error:
Unexpected Error occured:
System Error:#1: ORA-02042:too many distributed transactions 
ORA-02063:preceding line from DBNAME

DBNAME is the tnsnames setting for the remote database.

The MX_CONNECTION_POOL_SIZE needs to be set in the enovia.ini file (previously ematrix.ini) file, and the Oracle instance needs to be able to support more sessions than the connection pool size. For more information, see Oracle Configuration for Use with Adaplets.
Long datatype mapping fails for non-Oracle databasesWhen using a non-Oracle database and fetching columns defined as long, an ODBC error occurs if the long columns are not at the end of the table definition.Long columns are fetched differently than other columns. To fetch a long column, create a view of the table with the long columns at the end of the table definition. Then you can map the type/relationship to the view.
Using SQL Loader with long stringsWhen using SQL Loader to load data with long strings into Oracle, if the string descriptions exceed the lxDesc character size in the lxDesc control file you will encounter problems.If you have descriptions for objects that are longer than the 4096 default size defined for lxDesc, you must increase the lxDesc size. The lxDesc character size is given in the lxDesc_IDENTIFIER.ctl control file, where IDENTIFIER represents the vault holding the object descriptions. This example shows the contents of the control file with the last line showing the lxDesc default size of 4096:
LOAD DATA
INFILE lxDesc_026fe4e4.dat
INTO TABLE lxDesc_026fe4e4 append
  ( lxOid INTEGER EXTERNAL TERMINATED BY "|",
  lxKind INTEGER EXTERNAL TERMINATED BY "|",
  lxDesc CHAR(4096) TERMINATED BY "|" )