In this section: |
When the server accesses a data source, it needs to know how to interpret the data that it finds. For each data source the server will access, you create a synonym that describes the structure of the data source and the server mapping of the XML data types.
How to: Reference: |
Synonyms define unique names (or aliases) for each XML data structure that is accessible from a server. Synonyms are useful because they hide the location and identity of the underlying data source from client applications. They also provide support for extended metadata features of the server such as virtual fields and additional security mechanisms.
Using synonyms allows an object to be moved or renamed while enabling client applications to continue functioning without modification. The only modification required is a redefinition of the synonym on the server. The result of creating a synonym is a Master File and Access File based on a given XML document.
To create a synonym, you must have previously configured the adapter. You can create a synonym from the Applications or Adapters pages of the Web Console.
The Applications page opens.
The Select adapter to configure or Select connection to create synonym pane opens.
The first of a series of synonym creation panes opens.
The Status pane indicates that the synonym was created successfully.
The synonym is created and added under the specified application directory.
Note:
The following list describes the parameters for which you will need to supply values, and related tasks you will need to complete in order to create a synonym for the adapter. These options may appear on multiple panes. To advance from pane to pane, click the buttons provided, ending with the Create Synonym button, which generates the synonym based on your entries.
You can create a synonym based on either an XML document or an XML schema/DTD:
Select Document Instance parameters (Step 1)
Enables you to select a document instance from a URL. This selection requires a Base Location, Document Name, and Document Extension.
Defines the location of the document instance.
Enter the name of the XML document.
Enter the document extension. The default is xml.
Clicking this button enables you to create the synonym from the document instance, skipping Step 2.
Select Data Definition parameters (Step 2)
Enables you to select the schema or DTD from a URL. This selection requires a Base Location, Document Name, and Document Extension.
Defines the location of the schema or DTD.
Enter the name of the schema or DTD.
Enter the document extension. The default is xsd.
Create Synonym parameters (Step 3)
Synonym field names processing options
Select the Validate check box if you wish to convert all special characters to underscores and perform a name check to prevent the use of reserved names. (This is accomplished by adding numbers to the names.) This parameter ensures that names adhere to specifications. See Validation for Special Characters and Reserved Words for more information.
When the Validate option is unchecked, only the following characters are converted to underscores: '-'; ' '; ' \'; '/'; ','; '$'. No checking is performed for names.
Select the Make unique check box if you wish to set the scope for field and group names to the entire synonym. This ensures that no duplicate names are used, even in different segments of the synonym. When this option is unchecked, the scope is the segment.
Indicates the name that will be assigned to the synonym. To assign a different name, replace the displayed value.
When using a schema file (.xsd), this option includes more information in the synonym Access File. The additional information reflects CHOICE and SEQUENCE definitions of complex XML data types and is used in XML MODIFY.
Defines the XPATH to the element subtree on which the synonym will be based.
Select an application directory. The default value is baseapp.
If you have tables with identical table names, assign a prefix or a suffix to distinguish them. For example, if you have identically named human resources and payroll tables, assign the prefix HR to distinguish the synonyms for the human resources tables. Note that the resulting synonym name cannot exceed 64 characters.
If all tables and views have unique names, leave the prefix and suffix fields blank.
To specify that this synonym should overwrite any earlier synonym with the same fully qualified name, select the Overwrite existing synonyms check box.
Note: The connected user must have operating system write privileges in order to recreate a synonym.
XMLSLONG.dtd
<!ELEMENT Long_root_element (Long_entity_name,Line*,Comment*)> <!ATTLIST Long_root_element key CDATA #REQUIRED> <!ELEMENT Long_entity_name (#PCDATA)> <!ELEMENT Line (#PCDATA)> <!ELEMENT Comment (#PCDATA)> <!ENTITY a "11111111111111111111111111111111111111111111111111111111111"> <!ENTITY b "22222222222222222222222222222222222222222222222222222222222"> <!ENTITY c "33333333333333333333333333333333333333333333333333333333333"> <!ENTITY d "44444444444444444444444444444444444444444444444444444444444"> <!ENTITY e "55555555555555555555555555555555555555555555555555555555555"> <!ENTITY f "66666666666666666666666666666666666666666666666666666666666"> <!ENTITY g "77777777777777777777777777777777777777777777777777777777777"> <!ENTITY h "HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO"> <!ENTITY i "88888888888888888888888888888888888888888888888888888888888"> <!ENTITY j "12345678901234567890123456789012345678901234567890123456789"> <!ENTITY k "00000000000000000000000000000000000000000000000000000000000"> <!ENTITY l "date"> <!ENTITY n "name"> <!ENTITY p "It is possible to have">
To generate a synonym from the XMLSLONG DTD, enter the following information on the Create Synonym panes of the Web Console or the Data Management Console:
c:\xml\XMLSLONG.dtd
Note: If
you are using the ellipsis, enter dtd in
the Extension field and click the refresh
button, as shown in the following image.Generated Master File LONGNAME.mas
FILENAME=BASEAPP_LONGNAME, SUFFIX=XML , $ SEGMENT=LONG_ROOT_ELEMENT, SEGTYPE=S0, $ FIELDNAME=LONG_ROOT_ELEMENT, ALIAS=Long_root_element, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), $ FIELDNAME=LONG_ENTITY_NAME, ALIAS=Long_entity_name, USAGE=A10, ACTUAL=A10, REFERENCE=LONG_ROOT_ELEMENT, PROPERTY=ELEMENT, $ FIELDNAME=KEY, ALIAS=key, USAGE=A10, ACTUAL=A10, REFERENCE=LONG_ROOT_ELEMENT, PROPERTY=ATTRIBUTE, $ SEGMENT=LINE, SEGTYPE=S0, PARENT=LONG_ROOT_ELEMENT, $ FIELDNAME=LINE, ALIAS=Line, USAGE=A10, ACTUAL=A10, MISSING=ON, REFERENCE=LONG_ROOT_ELEMENT, PROPERTY=ELEMENT, $ SEGMENT=COMMENT, SEGTYPE=S0, PARENT=LONG_ROOT_ELEMENT, $ FIELDNAME=COMMENT, ALIAS=Comment, USAGE=A10, ACTUAL=A10, MISSING=ON, REFERENCE=LONG_ROOT_ELEMENT, PROPERTY=ELEMENT, $
Generated Access File Longname.acx
SEGNAME=LONG_ROOT_ELEMENT, LOCATION=C:\xml\XMLSLONG.dtd, $ ENTITY=p, VALUE=It is possible to have, $ ENTITY=n, VALUE=name, $ ENTITY=l, VALUE=date, $ ENTITY=k, VALUE=00000000000000000000000000000000000000000000000000000000000, $ ENTITY=j, VALUE=12345678901234567890123456789012345678901234567890123456789, $ ENTITY=i, VALUE=88888888888888888888888888888888888888888888888888888888888, $ ENTITY=h, VALUE=HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO HELLO, $ ENTITY=g, VALUE=77777777777777777777777777777777777777777777777777777777777, $ ENTITY=f, VALUE=66666666666666666666666666666666666666666666666666666666666, $ ENTITY=e, VALUE=55555555555555555555555555555555555555555555555555555555555, $ ENTITY=d, VALUE=44444444444444444444444444444444444444444444444444444444444, $ ENTITY=c, VALUE=33333333333333333333333333333333333333333333333333333333333, $ ENTITY=b, VALUE=22222222222222222222222222222222222222222222222222222222222, $ ENTITY=a, VALUE=11111111111111111111111111111111111111111111111111111111111, $
If there is no user-defined entity in the DTD, the Access File contains a $ sign. If there is a user-defined entity in the DTD, then the Access File contains the following for each entity
Eentity_name Ventity_value
where:
Is the entity name extracted from the DTD.
Is the entity value extracted from the DTD.
If you want to create a synomyn from a large XML schema or DTD, you can improve performance by using a subset based on a given position in the hierarchy. This creates a smaller synonym from a subtree (child element) of the XML root.
The syntax is:
CREATE SYNONYM child_element FOR schema.xsd DBMS XML AT app_dir PARMS POSITION=/parent_element/child_element DROP
END
where:
Is the subtree from which the synonym is created.
Is the schema on which the synonym is based.
Is the application directory where the synonym is created.
Indicates the position in the schema hierarchy.
Is the parent element located at the top-level of the schema hierarchy.
In the following example, the synomyn is created for the chapter subtree. The chapter is a child of the book element, which is located at the top-level of the xmlbook schema hierarchy:
CREATE SYNONYM chapter FOR xmlbook.xsd DBMS XML AT baseapp PARMS POSITION=/book/chapter DROP END
XPATH=/book is added to the Access File to indicate the position of chapter (the root segment in the synonym) in the schema hierarchy.
When issuing TABLE requests or writing XML based on the synonym, the actual path of the node is required. Since chapter is not the root node in the original schema, the path from the top of the schema to chapter is /book/chapter.
When writing XML files based on the synonym, the chapter element will be wrapped inside the book element, as in <book><chapter>...</chapter></book>.
When reporting on an XML file based on the synonym, you should overlook book since chapter is right under book.
Once you have created a synonym, you can right-click the synonym name in the Adapter navigation pane of either the Web Console or the Data Management Console to access the following options.
Option |
Description |
---|---|
Open |
Opens the Master File for viewing and editing using a graphical interface. If an Access file is used it will be also available. |
Edit as Text |
Enables you to view and manually edit the Master File synonym. Note: To update the synonym, it is strongly recommended that you use the graphical interface provided by the Open option, rather than manually editing the Master File. |
Edit Access File as Text |
Enables you to view and manually edit the Access File synonym. Note: This option is available only when an Access File is created as part of the synonym. |
Sample Data |
Retrieves up to 20 rows from the associated data source. |
Data Profiling |
Data Profiling provides the data characteristics for synonym columns. Alphanumeric columns provide the count of distinct values, total count, maximum, minimum, average length, and number of nulls. Numeric columns provide the count of distinct values, total count, maximum, minimum, average value, and number of nulls. |
Refresh Synonym (if applicable) |
Regenerates the synonym. Use this option if the underlying object has been altered. |
Data Management |
Followed by these options, if applicable: Recreate DBMS Table. Recreates the data source table. You are asked to confirm this selection before the table is regenerated. (Note that the table will be dropped and recreated. During the process, data may be lost.) Delete All Data. Deletes all existing data. You are asked to confirm this selection before the data is deleted. Insert Sample Data. Inserts specified number of sample records, populating all fields with counter values. Reorganize. Recreates the data source table preserving original data. Note: This option is not available in the Web Console. |
Impact Analysis |
Generates reports on procedures, synonyms, and columns that provide information on the flows/stored procedures available on a particular server, and the synonyms and columns they use. These reports enable you to evaluate changes before they are made by showing which components will be affected. See the Server Administration for UNIX, Windows, OpenVMS, IBM i, and z/OS manual for details about Impact Analysis reports. |
Copy |
Copies the synonym to the clipboard. |
Delete |
Deletes the synonym. You are asked to confirm this selection before the synonym is deleted. |
Cut |
Deletes the synonym and places it on the clipboard. |
Properties |
Displays the properties of the synonym, including physical location, last modified date, description, and privileges. |
How to: |
XML documents might be stored in any fields or columns in any data source. Reporting from such documents is supported by defining their structure as subtrees attached to a parent segment which describes the original data.
The synonym creation process must be run against the data in the DBMS and against the the XML document. The two Master Files must then be combined to make the XML Master File a child of the Master File created against the DBMS. A FILEDEF is not needed in this instance.
FILE=XMLPRO1 ,SUFFIX=SQLPRO ,$ SEGNAME=XMLPRO1 ,SEGTYPE=S0 ,$ FIELD=FLD1 ,FLD1 ,A2 ,A2 ,MISSING=ON ,$ FIELD=FLD2 ,FLD2 ,TX50 ,TX ,MISSING=ON ,$ FIELD=FLD3 ,FLD3 ,TX50 ,TX ,MISSING=ON ,$
Notice that this example has two TX columns, each of which contains different data and requires a separate segment declaration in the Master File.
The Map External XML option reads the XML data directly and creates the structure. The resulting Master File contains the definition of the XML data, represented as a new segment called SEGSUF=XML, which appears in the Text View pane following the original RDBMS segment. The Master File might look like the following:
FILE=XMLPRO1 ,SUFFIX=SQLPRO ,$ SEGNAME=XMLPRO1 ,SEGTYPE=S0 ,$ FIELD=FLD1 ,FLD1 ,A2 ,A2 ,MISSING=ON ,$ FIELD=FLD2 ,FLD2 ,TX50 ,TX ,MISSING=ON ,$ FIELD=FLD3 ,FLD33,TX50 ,TX ,MISSING=ON ,$ SEGMENT=ORDER, SEGTYPE=S0,POSITION=FLD2,PARENT=XMLPRO1,SEGSUF=XML, $ FIELDNAME=ORDER, ALIAS='Order', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATUS, ALIAS='Status', USAGE=A10, ACTUAL=A10, $ FIELDNAME=TOTALPRICE, ALIAS='TotalPrice', USAGE=A10, ACTUAL=A10, $ FIELDNAME=DATE, ALIAS='Date', USAGE=A10, ACTUAL=A10, $ FIELDNAME=PRIORITY, ALIAS='Priority', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CLERK, ALIAS='Clerk', USAGE=A10, ACTUAL=A10, $ FIELDNAME=SHIPPRIORITY,ALIAS='ShipPriority',USAGE=A10,ACTUAL=A10,$ FIELDNAME=COMMENT, ALIAS='Comment', USAGE=A10, ACTUAL=A10, $ SEGMENT=PORDER, SEGTYPE=S0,POSITION=FLD3,PARENT=XMLPRO1,SEGSUF=XML $ FIELDNAME=PORDER, ALIAS='Order', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=ADDRESS, ALIAS='Address', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATE, ALIAS='State', USAGE=A10, ACTUAL=A10, $
Tip: If you have a TX column that contains multiple XML formats (for example, a name field and an address field), you can choose Map External XML multiple times to create a separate SEGSUF=XML segment for each format.
Suppose that you have a table in an RDBMS with one or more columns storing XML data. In order to report from the XML data, following these steps:
FILE=XMLPRO1 ,SUFFIX=SQLPRO ,$ SEGNAME=XMLPRO1 ,SEGTYPE=S0 ,$ FIELD=FLD1 ,FLD1 ,A2 ,A2 ,MISSING=ON ,$ FIELD=FLD2 ,FLD2 ,TX50 ,TX ,MISSING=ON ,$ FIELD=FLD3 ,FLD3 ,TX50 ,TX ,MISSING=ON ,$
FILENAME=BASEAPP/ORDER, SUFFIX=XML , $ SEGMENT=ORDER, SEGTYPE=S0, $ FIELDNAME=ORDER, ALIAS='Order', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATUS, ALIAS='Status', USAGE=A10, ACTUAL=A10, $ FIELDNAME=TOTALPRICE, ALIAS='TotalPrice', USAGE=A10, ACTUAL=A10, $ FIELDNAME=DATE, ALIAS='Date', USAGE=A10, ACTUAL=A10, $ FIELDNAME=PRIORITY, ALIAS='Priority', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CLERK, ALIAS='Clerk', USAGE=A10, ACTUAL=A10, $ FIELDNAME=SHIPPRIORITY,ALIAS='ShipPriority',USAGE=A10,ACTUAL=A10,$ FIELDNAME=COMMENT, ALIAS='Comment', USAGE=A10, ACTUAL=A10, $ FILENAME=BASEAPP/PORDER, SUFFIX=XML , $ SEGMENT=PORDER, SEGTYPE=S0, $ FIELDNAME=PORDER, ALIAS='POrder', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=ADDRESS, ALIAS='Address', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATE, ALIAS='State', USAGE=A10, ACTUAL=A10, $
Combined Master file:
FILE=XMLPRO1 ,SUFFIX=SQLPRO ,$ SEGNAME=XMLPRO1 ,SEGTYPE=S0 ,$ FIELD=FLD1 ,FLD1 ,A2 ,A2 ,MISSING=ON ,$ FIELD=FLD2 ,FLD2 ,TX50 ,TX ,MISSING=ON ,$ FIELD=FLD3 ,FLD33,TX50 ,TX ,MISSING=ON ,$ SEGMENT=ORDER, SEGTYPE=S0,POSITION=FLD2,PARENT=XMLPRO1,SEGSUF=XML, $ FIELDNAME=ORDER, ALIAS='Order', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATUS, ALIAS='Status', USAGE=A10, ACTUAL=A10, $ FIELDNAME=TOTALPRICE, ALIAS='TotalPrice', USAGE=A10, ACTUAL=A10, $ FIELDNAME=DATE, ALIAS='Date', USAGE=A10, ACTUAL=A10, $ FIELDNAME=PRIORITY, ALIAS='Priority', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CLERK, ALIAS='Clerk', USAGE=A10, ACTUAL=A10, $ FIELDNAME=SHIPPRIORITY,ALIAS='ShipPriority',USAGE=A10,ACTUAL=A10,$ FIELDNAME=COMMENT, ALIAS='Comment', USAGE=A10, ACTUAL=A10, $ SEGMENT=PORDER, SEGTYPE=S0,POSITION=FLD3,PARENT=XMLPRO1,SEGSUF=XML $ FIELDNAME=PORDER, ALIAS='Order', USAGE=A1, ACTUAL=A1, $ FIELDNAME=KEY, ALIAS='key', USAGE=A10, ACTUAL=A10, $ FIELDNAME=CUSTOMER, ALIAS='Customer', USAGE=A10, ACTUAL=A10, $ FIELDNAME=ADDRESS, ALIAS='Address', USAGE=A10, ACTUAL=A10, $ FIELDNAME=STATE, ALIAS='State', USAGE=A10, ACTUAL=A10, $
You can describe various views of the same physical XML document using Master Files and Access Files.
The adapter implements join matching values at run time.
You can use static Joins to create join relationships between hierarchically unrelated integral schema ComplexType definitions using any combination of data nodes.
Any XML tags belonging to these definitions can be used to create join pairs. In addition, you can multiply instances of the same physical segment to reflect logical join relationships as needed.
Note: Static (embedded) Joins are not directly supported by the Create Synonym facility. To take advantage of this feature, after a synonym is generated you must modify its Master and Access Files. The Data Management Console Synonym Editor is the recommended tool for such modifications since it provides an easily identifiable segments hierarchy with drag and drop capability and a visual calculator for KEYFLD/IXFLD modifications. Using the Data Management Console, you can quickly add all duplicate segments to the Master File, then delete any unneeded segments.
In some cases, schemas (such as those produced by Microsoft tools and reflecting relationships between the original MS SQL Server database tables) contain proper XML constraints (unique/key/keyref) for describing joins. You can use this information to modify the Master File:
For an illustration of such a schema, seeModifying Master and Access Files Produced From Schema Exported by an SQL Server.
Suppose that two links exist in the schema defined in the file GetAllEmployeesFullDS.xml between the elements Employee and EmployeeTL (segments EMPLOYEE and EMPLOYEETL in the Master File). Two variations follow:
Defines EmployeeTL --> Employee joined by EId/EId pair
In this example, segment EMPLOYEE becomes the child of segment EMPLOYEETL in the Master File, and the Access File describes the foreign and primary keys as follows:
<xs:unique name="Constraint1" msdata:PrimaryKey="true"> <xs:selector xpath=".//Employee" /> <xs:field xpath="EId" /> </xs:unique> <xs:keyref name="EmployeeTl_Employee_EId_EId" refer="Constraint1" msdata:ConstraintOnly="true"> <xs:selector xpath=".//EmployeeTl" /> <xs:field xpath="EId" /> </xs:keyref>
Access File
SEGNAME=EMPLOYEE, KEYFLD=EID, IXFLD=EID, $
Defines Employee --> EmployeeTL joined relationship by TLInformation/EtId pair
In this example, segment EMPLOYEETL becomes the child of segment EMPLOYEE in the Master File, and the Access File describes the foreign and primary keys as follows:
<xs:unique name="EmployeeTl_Constraint1" msdata:ConstraintName="Constraint1" msdata:PrimaryKey="true"> <xs:selector xpath=".//EmployeeTl" /> <xs:field xpath="EtId" /> </xs:unique> <xs:keyref name="Employee_EmployeeTl_EtId_TLInformation" refer="EmployeeTl_Constraint1" msdata:ConstraintOnly="true"> <xs:selector xpath=".//Employee" /> <xs:field xpath="TLInformation" /> </xs:keyref>
Access File
SEGNAME=EMPLOYEETL, KEYFLD=TLINFORMATION, IXFLD=ETID, $
This example illustrates an original structure without a static join and the modifications made to reflect the use of static Joins.
Original Structure Without Static Joins
In this native structure all child segments have a common parent; the root segment GETALLEMPLOYEERESULTS.
In the corresponding Master File generated as part of the synonym, the PARENT attribute of each segment declaration describes the logical relationships among segments, while the REFERENCE attribute for each field provides information about the physical parent/child relationships among the elements in the file.
Generated Master File
FILENAME=GETALLEMPLOYEEFULLDS, SUFFIX=XML, DATASET=C:\Users\yn05149\apps\xml\GetAllEmployeesFullDS.xml, $ $
SEGMENT=GETALLEMPLOYEESRESULT, SEGTYPE=S0, $ FIELDNAME=GETALLEMPLOYEESRESULT, ALIAS=GetAllEmployeesResponse, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), $ FIELDNAME=GETALLEMPLOYEESRESULT1, ALIAS=GetAllEmployeesResult, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), REFERENCE=GETALLEMPLOYEESRESULT, PROPERTY=ELEMENT, $ FIELDNAME=DIFFGRAM, ALIAS=diffgram, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), REFERENCE=GETALLEMPLOYEESRESULT1, PROPERTY=ELEMENT, $ FIELDNAME=DSEMPLOYEE, ALIAS=DSEmployee, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), REFERENCE=DIFFGRAM, PROPERTY=ELEMENT, $ $
SEGMENT=DATASETGENERATOR, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $ FIELDNAME=DATASETGENERATOR, ALIAS=DataSetGenerator, USAGE=A1, ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), REFERENCE=DSEMPLOYEE, PROPERTY=ELEMENT, $ FIELDNAME=OBJECTTYPE, ALIAS=ObjectType, USAGE=A30, ACTUAL=A30, REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $ FIELDNAME=ISCOLLECTION, ALIAS=IsCollection, USAGE=A5, ACTUAL=A5, REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $ FIELDNAME=OBJECTID, ALIAS=ObjectId, USAGE=I11, ACTUAL=A11, REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $ $
SEGMENT=EMPLOYEE, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=EMPLOYEE, ALIAS=Employee, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=DSEMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=CITYIDBIRTHPLACE, ALIAS=CityIdBirthplace, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=TLID, ALIAS=TlId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EFIRSTNAME, ALIAS=EFirstname, USAGE=A30, ACTUAL=A30,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=ENAME, ALIAS=EName, USAGE=A30, ACTUAL=A30,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EBIRTHDATE, ALIAS=EBirthdate, USAGE=HYYMDm, ACTUAL=A35,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=IEID, ALIAS=IeId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=TLINFORMATION, ALIAS=TLInformation, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
$
SEGMENT=EMPLOYEETL, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=EMPLOYEETL, ALIAS=EmployeeTl, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=ETID, ALIAS=EtId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=AIDOFFICIAL, ALIAS=AIdOfficial, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=AIDRESIDENTIAL, ALIAS=AIdResidential, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=DEPID, ALIAS=DepId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
$
SEGNAME=ADDRESS, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=ADDRESS, ALIAS=Address, USAGE=A1, ACTUAL=A1,
PROPERTY=ELEMENT, REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE,
ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=AID, ALIAS=AId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
FIELDNAME=AADDRESS, ALIAS=AAddress, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
FIELDNAME=AADDRESSNMBR, ALIAS=AAddressNmbr, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
FIELDNAME=ATEL1, ALIAS=ATel1, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
FIELDNAME=ATEL2, ALIAS=ATel2, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=ADDRESS, $
$
SEGNAME=CITY, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=CITY, ALIAS=City, USAGE=A1, ACTUAL=A1, PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=CITY, $
FIELDNAME=COUNTRYID, ALIAS=CountryId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=CITY, $
FIELDNAME=CITYNAME, ALIAS=CityName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=CITY, $
FIELDNAME=CITYPOSTALCODE, ALIAS=CityPostalcode, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=CITY, $
$
SEGNAME=EMPLOYEERELATIVE, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=EMPLOYEERELATIVE, ALIAS=EmployeeRelative, USAGE=A1, ACTUAL=A1,
PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=ERID, ALIAS=ErId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=CITYIDBIRTHPLACE, ALIAS=CityIdBirthplace, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=TLID, ALIAS=TlId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=ERLRELATIONSHIP, ALIAS=ErLRelationship, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=ERNAME, ALIAS=ErName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
FIELDNAME=ERFIRSTNAME, ALIAS=ErFirstname, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE, $
$
Generated Access File. When you create a synonym, the generated Access File stores entity abbreviations but does not contain other content. However, you can open and edit this file to make any required modifications, as will be illustrated shortly in the structure that defines static Joins.
Modified Structure With Static Joins
In the modified structure, the original two-level organization is replaced by a five-level structure in which some instances of the same physical segments (CITY and ADDRESS) have been multiplied to reflect the new logical Join relationships.
Modified Master File
In the corresponding Master File, parent/child relationships have been manually expanded and rearranged and references have been revised to provide accurate pointers through the new hierarchy.
As you look at this Master File, keep the following information in mind:
segment.fieldname
As a rule, the adapter attempts to resolve each reference in the current segment. If that cannot be accomplished, it searches for the first occurrence of the REFERENCE in the parent chain. (This is illustrated by the REFERENCE attributes in SEGMENT EMPLOYEETL.) Qualified (two-part) references force the direct resolution in the specified segment. (This is illustrated by the REFERENCE attributes in SEGMENT EMPLOYEERELATIVE.) Both notations are correct and produce the same result in this example.
FILENAME=GETALLEMPLOYEEFULLDS, SUFFIX=XML, DATASET=C:\Users\yn05149\apps\xml\GetAllEmployeesFullDS.xml, $ $
SEGMENT=GETALLEMPLOYEESRESULT, SEGTYPE=S0, $
FIELDNAME=GETALLEMPLOYEESRESULT, ALIAS=GetAllEmployeesResponse, USAGE=A1,
ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=GETALLEMPLOYEESRESULT1, ALIAS=GetAllEmployeesResult, USAGE=A1,
ACTUAL=A1, ACCESS_PROPERTY=(INTERNAL),
REFERENCE=GETALLEMPLOYEESRESULT, PROPERTY=ELEMENT, $
FIELDNAME=DIFFGRAM, ALIAS=diffgram, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=GETALLEMPLOYEESRESULT1, PROPERTY=ELEMENT, $
FIELDNAME=DSEMPLOYEE, ALIAS=DSEmployee, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=DIFFGRAM, PROPERTY=ELEMENT, $
$
SEGMENT=DATASETGENERATOR, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=DATASETGENERATOR, ALIAS=DataSetGenerator, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=DSEMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=OBJECTTYPE, ALIAS=ObjectType, USAGE=A30, ACTUAL=A30,
REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $
FIELDNAME=ISCOLLECTION, ALIAS=IsCollection, USAGE=A5, ACTUAL=A5,
REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $
FIELDNAME=OBJECTID, ALIAS=ObjectId, USAGE=I11, ACTUAL=A11,
REFERENCE=DATASETGENERATOR, PROPERTY=ELEMENT, $
$
SEGMENT=EMPLOYEE, SEGTYPE=S0, PARENT=GETALLEMPLOYEESRESULT, $
FIELDNAME=EMPLOYEE, ALIAS=Employee, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=DSEMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=CITYIDBIRTHPLACE, ALIAS=CityIdBirthplace, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=TLID, ALIAS=TlId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EFIRSTNAME, ALIAS=EFirstname, USAGE=A30, ACTUAL=A30,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=ENAME, ALIAS=EName, USAGE=A30, ACTUAL=A30,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=EBIRTHDATE, ALIAS=EBirthdate, USAGE=HYYMDm, ACTUAL=A35,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=IEID, ALIAS=IeId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=TLINFORMATION, ALIAS=TLInformation, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEE, PROPERTY=ELEMENT, $
$
SEGMENT=EMPLOYEETL, SEGTYPE=S0, PARENT=EMPLOYEE, $
FIELDNAME=EMPLOYEETL, ALIAS=EmployeeTl, USAGE=A1, ACTUAL=A1,
ACCESS_PROPERTY=(INTERNAL),
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, PROPERTY=ELEMENT, $
FIELDNAME=ETID, ALIAS=EtId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=AIDOFFICIAL, ALIAS=AIdOfficial, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=AIDRESIDENTIAL, ALIAS=AIdResidential, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
FIELDNAME=DEPID, ALIAS=DepId, USAGE=I11, ACTUAL=A11,
REFERENCE=EMPLOYEETL, PROPERTY=ELEMENT, $
$
SEGNAME=OADDRESS, SEGTYPE=S0, PARENT=EMPLOYEETL, $
FIELDNAME=ADDRESS, ALIAS=Address, USAGE=A1, ACTUAL=A1,
PROPERTY=ELEMENT, REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE,
ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=AID, ALIAS=AId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
FIELDNAME=AADDRESS, ALIAS=AAddress, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
FIELDNAME=AADDRESSNMBR, ALIAS=AAddressNmbr, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
FIELDNAME=ATEL1, ALIAS=ATel1, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
FIELDNAME=ATEL2, ALIAS=ATel2, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
$
SEGNAME=OCITY, SEGTYPE=S0, PARENT=OADDRESS, $
FIELDNAME=CITY, ALIAS=City, USAGE=A1, ACTUAL=A1, PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=OCITY.CITY, $
FIELDNAME=COUNTRYID, ALIAS=CountryId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=OCITY.CITY, $
FIELDNAME=CITYNAME, ALIAS=CityName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OCITY.CITY, $
FIELDNAME=CITYPOSTALCODE, ALIAS=CityPostalcode, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OCITY.CITY, $
$
SEGNAME=RADDRESS, SEGTYPE=S0, PARENT=EMPLOYEETL, $
FIELDNAME=ADDRESS, ALIAS=Address, USAGE=A1, ACTUAL=A1,
PROPERTY=ELEMENT, REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE,
ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=AID, ALIAS=AId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=RADDRESS.ADDRESS, $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=RADDRESS.ADDRESS, $
FIELDNAME=AADDRESS, ALIAS=AAddress, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=RADDRESS.ADDRESS, $
FIELDNAME=AADDRESSNMBR, ALIAS=AAddressNmbr, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=RADDRESS.ADDRESS, $
FIELDNAME=ATEL1, ALIAS=ATel1, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=RADDRESS.ADDRESS, $
FIELDNAME=ATEL2, ALIAS=ATel2, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=OADDRESS.ADDRESS, $
$
SEGNAME=RCITY, SEGTYPE=S0, PARENT=RADDRESS, $
FIELDNAME=CITY, ALIAS=City, USAGE=A1, ACTUAL=A1, PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=RCITY.CITY, $
FIELDNAME=COUNTRYID, ALIAS=CountryId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=RCITY.CITY, $
FIELDNAME=CITYNAME, ALIAS=CityName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=RCITY.CITY, $
FIELDNAME=CITYPOSTALCODE, ALIAS=CityPostalcode, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=RCITY.CITY, $
$
SEGNAME=BCITY, SEGTYPE=S0, PARENT=EMPLOYEE, $
FIELDNAME=CITY, ALIAS=City, USAGE=A1, ACTUAL=A1, PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=CITYID, ALIAS=CityId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=BCITY.CITY, $
FIELDNAME=COUNTRYID, ALIAS=CountryId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=BCITY.CITY, $
FIELDNAME=CITYNAME, ALIAS=CityName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=BCITY.CITY, $
FIELDNAME=CITYPOSTALCODE, ALIAS=CityPostalcode, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=BCITY.CITY, $
$
SEGNAME=EMPLOYEERELATIVE, SEGTYPE=S0, PARENT=EMPLOYEE, $
FIELDNAME=EMPLOYEERELATIVE, ALIAS=EmployeeRelative, USAGE=A1, ACTUAL=A1,
PROPERTY=ELEMENT,
REFERENCE=GETALLEMPLOYEESRESULT.DSEMPLOYEE, ACCESS_PROPERTY=(INTERNAL), $
FIELDNAME=ERID, ALIAS=ErId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=EID, ALIAS=EId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=CITYIDBIRTHPLACE, ALIAS=CityIdBirthplace, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=TLID, ALIAS=TlId, USAGE=I11, ACTUAL=A11,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=ERLRELATIONSHIP, ALIAS=ErLRelationship, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=ERNAME, ALIAS=ErName, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
FIELDNAME=ERFIRSTNAME, ALIAS=ErFirstname, USAGE=A30, ACTUAL=A30,
PROPERTY=ELEMENT, REFERENCE=EMPLOYEERELATIVE.EMPLOYEERELATIVE, $
$
Modified Access File
The modified Access File shows which keys are used in the logical structure of the Join:
SEGNAME=EMPLOYEETL, KEYFLD=TLINFORMATION, IXFLD=ETID, $ SEGNAME=OADDRESS, KEYFLD=AIDOFFICIAL, IXFLD=AID, $ SEGNAME=OCITY, KEYFLD=CITYID, IXFLD=CITYID, $ SEGNAME=RADDRESS, KEYFLD=AIDRESIDENTIAL, IXFLD=AID, $ SEGNAME=RCITY, KEYFLD=CITYID, IXFLD=CITYID, $ SEGNAME=BCITY, KEYFLD=CITYIDBIRTHPLACE, IXFLD=CITYID, $ SEGNAME=EMPLOYEERELATIVE, KEYFLD=EID, IXFLD=EID, $
How to: |
The Create Synonym process uses a DTD, XSD, or XML document as the source for creating the synonym. DTDs do not contain data type descriptions, therefore the actual and usage attributes of all fields in the Master File are set to ALPHA data type.
If you try to perform arithmetic operations (-, +, >, <) on fields that are numbers or dates in the XML document but are mapped as ALPHA in the Master File, you may not get the expected results since the arithmetic operations are performed on string literals. To override this problem you may modify the USAGE attribute of a field as described in the following sections.
Note: The data type defined in the ACTUAL attribute of a field must remain as ALPHA.
In order to change the default setting you must issue the SET VARCHAR command.
The following table lists how the server maps XSD data types in a Master File. You can change some of these mapping defaults, as described in Changing the Length of Character Strings and Changing the Precision and Scale of Numeric Columns.
XSD Data Type |
USAGE Attribute |
ACTUAL Attribute |
---|---|---|
decimal |
P20.3 |
A20 |
integer |
P33 |
A33 |
nonPositiveInteger |
33 |
A33 |
negativeInteger |
P33 |
A33 |
boolean |
A5 |
A5 |
long |
P20 |
A20 |
int |
I11 |
A11 |
short |
I6 |
A6 |
byte |
I4 |
A4 |
nonNegativeInteger |
P32 |
A32 |
unsignedLong |
P20 |
A20 |
unsignedInt |
P10 |
A10 |
unsignedShort |
I5 |
A5 |
unsignedByte |
I4 |
A4 |
positiveInteger |
P32 |
A32 |
double |
D20.2 |
A20 |
float |
F15.2 |
A15 |
dateTime |
HYYMDm |
A27 |
time |
HHISsm |
A15 |
date |
YYMD |
A10 |
gYearMonth |
HYYM |
A8 |
gYear |
HYY |
A5 |
gMonthDay |
HMD |
A6 |
gDay |
HD |
A3 |
gMonth |
HM |
A4 |
string |
A30 |
A30 |
normalizedString |
A30 |
A30 |
token |
A30 |
A30 |
Name |
A30 |
A30 |
NMTOKEN |
A30 |
A30 |
ID |
A30 |
A30 |
hexBinary |
A30 |
A30 |
language |
A30 |
A30 |
anyURI |
A30 |
A30 |
QName |
A30 |
A30 |
ENGINE XML SET VARCHAR {ON|OFF}
The ACTUAL and USAGE attributes of each field in the Master File is set arbitrarily to A10. You can override this setting using the SET FIELDLENGTH command
ENGINE XML SET FIELDLENGTH nnn
where:
Is the length assigned to actual and usage attributes of all fields in the Master File during the create synonym process. The maximum length is 3000.
How to: |
By default, when the Adapter for XML creates a synonym, it maps all fields defined as string in the XML schema to 10-byte fixed-length alphanumeric in the Master File. You can change the length (the variability and the number of bytes) using the SET VARCHAR and SET LENGTH commands.
By default, when the Adapter for XML creates a synonym, it maps all fields defined as string in the XML schema to fixed-length alphanumeric in the Master File. You can change this default to variable length using the SET VARCHAR command
ENGINE XML SET VARCHAR {ON|OFF}
where:
Indicates the adapter. You can omit this value if you previously issued the SET SQLENGINE command.
Maps all fields defined as string in the XML schema to variable-length alphanumeric (AnV) in the Master File's USAGE and ACTUAL attributes.
Maps all fields defined as string in the XML schema to fixed-length alphanumeric (A) in the Master File's USAGE and ACTUAL attributes. This is the default.
By default, when the Adapter for XML creates a synonym, it maps all fields defined as string in the XML schema to 10-byte alphanumeric in the Master File. You can change this default length using the SET FIELDLENGTH command
ENGINE XML XML SET FIELDLENGTH length
where:
Indicates the adapter. You can omit this value if you previously issued the SET SQLENGINE command.
Is the length, in bytes, assigned to the ACTUAL and USAGE attributes of all fields defined in the XML schema as string. The maximum length is 3000.
How to: |
You can alter the length and scale of numeric columns returned by a SELECT request to the server by creating different specifications in your login profile or in a stored procedure. The conversion settings are reflected in the Master File in the USAGE and ACTUAL formats of the fields generated by CREATE SYNONYM. This affects how the fields are processed and formatted by the server.
Tip: You can change this setting manually or from the Web Console.
ENGINE XML SET CONVERSION RESET ENGINE XML SET CONVERSION format RESET ENGINE XML SET CONVERSION format [PRECISION precision [scale]] ENGINE XML SET CONVERSION format [PRECISION MAX]
where:
Indicates the adapter. You can omit this value if you previously issued the SET SQLENGINE command.
Returns any previously specified precision and scale values to the adapter defaults. If you specify RESET immediately following the SET CONVERSION command, all data types return to the defaults. If you specify RESET following a particular data type, only columns of that data type are reset.
Is any valid format supported by the data source. Possible values are:
INTEGER which indicates that the command applies only to INTEGER columns.
DECIMAL which indicates that the command applies only to DECIMAL columns.
REAL which indicates that the command applies only to single-precision floating-point columns.
Note: Only applies to DB2, CA-IDMS/SQL, Microsoft SQL Server, and Sybase.
FLOAT which indicates that the command applies only to double-precision floating-point columns.
Is the precision. Must be greater than 1 and less than or equal to the maximum allowable value for the data type (see the description of MAX).
Is the scale. This is valid with DECIMAL, FLOAT and REAL data types. If you do not specify a value for scale, the current scale setting remains in effect. The default scale value is 2.
If the scale is not required, you must set the scale to 0 (zero).
Sets the precision to the maximum allowable value for the indicated data type:
Data Type |
MAX Precision |
---|---|
INTEGER |
11 |
DECIMAL |
18 |
REAL |
9 |
FLOAT |
20 |
Note: When issuing the CREATE SYNONYM command while the CONVERSION command is active in the profile, the Master File reflects the scale and length that is set by the CONVERSION command.
However, when issuing a SELECT statement, the answer set description does not use the information in the Master File. The length and scale used for the answer set description depends on whether a CONVERSION command is in effect.
If a CONVERSION command is in effect, the answer set description uses the length and scale that is set by the CONVERSION command.
If a CONVERSION command is not in effect, the answer set description uses the actual length and scale of the data.
The following example shows how to set the precision attribute for all INTEGER and SMALLINT fields to 7:
ENGINE XML SET CONVERSION INTEGER PRECISION 7
The following example shows how to set the precision attribute for all DOUBLE PRECISION fields to 14 and the scale attribute to 3:
ENGINE XML SET CONVERSION FLOAT PRECISION 14 3
The following example shows how to set the precision attribute for all INTEGER and SMALLINT fields to the default:
ENGINE XML SET CONVERSION INTEGER RESET
The following example shows how to set the precision and scale attributes for all fields to the defaults:
ENGINE XML SET CONVERSION RESET
The data in an XML document may reflect dates or numeric values, however, all the fields in a Master File synonym are set to the ALPHA data type.
In order to enable arithmetic operations on numeric fields, the data type specified in the USAGE attribute of a numeric field needs to be modified, depending on the data in the XML document, to one of the following data types: Integer (I), Double Float (D) or Decimal (P). If the data type is modified to Double Float or Decimal, use scale and precision as necessary to describe the data in the XML document.
Furthermore, it is recommended that the length of the ALPHA data type specified in the ACTUAL attribute of the numeric field be modified to reflect the maximum length of the data in the XML document.
In order to enable arithmetic operations on dates, the data type specified in the USAGE attribute of a date field needs to be modified, depending on the date format used in the XML document, to one of the following data types: YYMD, MDYY or DMYY.
Furthermore, the length of the ALPHA data type specified in the ACTUAL attribute of the date field needs to be modified to 10.
Note:
If in the XML document you have the following format: |
Then use USAGE= |
---|---|
1996-01-30 |
YYMD |
01-30-1996 |
MDYY |
30-01-1996 |
DMYY |
iWay Software |