Limitations


Limitation	Description
Duplicate objects	Depending on the implementation of the legacy system and how that adaplet mapping file is constructed, it could be possible to create objects with duplicate type/name/revisions. The two objects will have different ids in the oracle table and different oids in the 3DSpace table. For more information, see Mapping File Syntax.
Modification of joined data	If there are attributes on a type or relationship that are constructed using a join of two different tables, an end user cannot update the attributes.
Transaction management	Adaplet technology expects that the API to the foreign system supports transaction management. When this expectation is not realized, foreign vaults behave quite differently from local vaults.
Order of types	The order of types in an adaplet vault cannot be changed. New types must be added at the end, and a type may not be removed. The order of the "type" definitions in the map file corresponds to an ordinal position starting at "0". This ordinal position value becomes part of the oid for the object in 3DSpace when running in "extend" mode (the first 7 bits of the 32-bit value). Adding a type definition anywhere but the end of the map file will change the positions from that entry on and invalidate all oids for the types and relationship connections using mappings after it. You can put a type after a relationship type (for example, at the end) only if the relationship type does not list that type in its definition. You cannot add a type and then include it in the “from” or “to” side of an existing relationship type. If you are using version 8 adaplets code, these rules are only true if some object in the vault has been extended. However, in version 9 these rules are generally true. For example, in version 9 these rules apply if there are any rows in the lxForeign table, which happens to any kind of an adaplet when a query is performed that returns one or more objects.
Changing types	In extend mode adaplets, when you change the type of an object that is locked in the adaplet vault, both the new and old object display when you query the vault.
Wildcard searches in extend mode	In extend mode adaplets, when searching for objects using the wildcard character () in the name field, wildcard searches are successful when using letters, but inconsistent when using numbers. For example, a search on A* in a name yields good results, but a search on 2 may not return all possible names with the number 2. The wildcard character can be used in any position in the search string, for example. A, A, or A.
SQL Loader and date fields	When using SQL Loader, the format of date fields written to the lxbo_xxx.dat files, and the date mask specified in the .ctl file, is YYYYMMDD. Therefore, all dates extracted from the foreign tables that are accurate to the second will get truncated to the day when loaded via SQL Loader.
Relationships using derived types	The use in the mapping file of a derived type at the end of a relationship type does not work correctly. For example, in a sample Oracle adaplet, if the definition of the relationship called “Manager” in a mapping file is changed so that the to-type is “Analyst” (a derived type) rather than “Employee”, the following results will be found in MQL: MQL<12>expand bus President KING ''; 1 Manager to Analyst JONES 1 Manager to Analyst BLAKE 1 Manager to Analyst CLARK 1 Department from Department ACCOUNTING 1 Salary Grade from Salary Grade 5 MQL<13>expand bus Manager JONES ''; 1 Manager to Analyst SCOTT 1 Department from Department RESEARCH 1 Salary Grade from Salary Grade 4 MQL<14>expand bus Analyst JONES ''; Error: #1900068: expand business object failed Error: #1500029: No business object 'Analyst JONES ' found There is no "Analyst JONES", although he is listed on the to-end of a Manager relationship from President KING. Moreover, "Manager JONES" (the only JONES in the vault) has no such relationship. Instead of using MQL, a workaround is to use views so that to the adaplet all objects are at the same hierarchy level.