Database considerations

The following considerations apply to using the iSeries™ Access for Web database functions in a Web application server environment.

The database considerations can be grouped into these functional categories:
Start of changeDatabase connectionsEnd of change
Start of changeiSeries Access for Web makes JDBC calls to access database tables. By default, the IBM® Toolbox for Java™ JDBC driver is used to establish a driver manager connection to the iSeries server running iSeries Access for Web. The customize function provides support for defining additional database connections. Additional connections can be defined to access different iSeries servers, to specify different driver settings, or to use different JDBC drivers. If a different JDBC driver is used in a single sign-on (SSO) environment, any required authentication values must be set on the JDBC URL.
The customize function also provides support for defining data source connections. This support is only available in the WebSphere® application server environment. Version 4 data sources are not supported. If iSeries Access for Web is configured to use basic authentication to prompt for the iSeries user profile and password, these user and password values are also used to authenticate the data source connection. If iSeries Access for Web is running in an SSO environment, the data source must have a component-managed authentication alias configured.
Note: iSeries Access for Web is tested using the IBM Toolbox for Java JDBC driver. Using a different driver might work, but this is an untested and unsupported environment.
For a list of the different connection properties that are recognized by the JDBC driver, refer to the "IBM Toolbox for Java JDBC properties" topic.
End of change
Run SQL: Output types
The supported output types for returning SQL statement result data are:
Extensible markup language (.xml)
The XML output generated by Run SQL is a single document containing both an embedded schema and results from the SQL query. The embedded schema is compliant with the W3C Schema Recommendation dated May 2, 2001. The schema contains meta information for the query results portion of the document. Contained in the schema is data type information, limits on data, and document structure.

Current XML parser implementations do not support validation using the embedded approach. Many parsers, including SAX and DOM implementations, require independent documents for the schema and content to do validation. To achieve schema validation with an XML document produced by Run SQL, the document must be restructured into individual data and schema documents. The root elements must also be updated to support this new structure. Visit the World Wide Web Consortium's Web site for additional information about XML Schema.

The query results portion of the XML document contains the data returned from the query in a structured row and column fashion. This data may be easily processed by other applications. If more information about the data contained in this topic is required, reference can be made to the document schema.

Hypertext markup language (.html)
When the HTML output type is being used, the results are displayed in the browser. To save the results to a file, the browser save function can be used. Another option is to save the SQL request and to redirect the results to a file when the request is run. With Internet Explorer, right-click the Run link and choose the Save Target As option. With Netscape Navigator, hold down the shift key while clicking the Run link.

If the HTML rows per table value is set, Run SQL will display the results in a paged list, similar to Preview, instead of returning a single HTML page.

Microsoft Excel/Lotus 1-2-3
The supported file formats for Microsoft Excel and Lotus 1-2-3 are not the newest types supported by these applications. Since the additional capabilities of the newer types are not likely to be needed for retrieving data from a database, this should not result in a loss of functionality. By supporting the older versions of these file types, compatibility can be retained for the older versions of these applications. A newer version of the application can be used to save the results to a file in a newer format.
Note: The file in the new format is not compatible with Copy data to table.
Microsoft Excel XML (.xml)
The Microsoft Excel XML file format is only supported by Microsoft Excel 2002 or newer versions of the application. Microsoft Excel 2002 is part of Microsoft Office XP.
Portable document format (.pdf)
The PDF file format represents your SQL data as it would appear on a page. The amount of data that can fit on a page depends on the page size, the page orientation, and the margin sizes. A very large number of columns can result in an unusable PDF document. In some cases, the Adobe Acrobat Reader plug-in cannot load a file like this into the browser. As an alternative, you can break the request into multiple queries, which return subsets of the columns, or you can choose a different output type.

Using the output settings, you can customize the selection of fonts used for the various parts of the PDF document. You can embed the chosen fonts into the document, rather than installing them on the computer used to view the document. Embedding fonts in the document increases the document size.

The character encoding used to represent text is also a PDF output option. If the font is not able to represent a character in the encoding, the character is left blank or another indicator character is used to show the character cannot be displayed. You should choose font and character set values which are capable of representing all characters in the data to display.

By default, Run SQL supports the standard PDF fonts and the Adobe Asian fonts for building PDF output. Since the standard fonts are required to be available with any PDF viewer, there is no need to embed them in the PDF document. Adobe provides a set of Asian font packs for displaying text containing Simplified Chinese, Traditional Chinese, Japanese, or Korean characters. Run SQL supports creating documents with these fonts, but it does not support embedding these fonts in the document. If these fonts are used, the appropriate font pack needs to be installed on the computer used to view the document. These font packs can be downloaded from Adobe's Web site.

Additional fonts can be added to the available fonts list, using the "Additional PDF font directories" Customization setting. The supported font types are:

  • Adobe Type 1 fonts (*.afm)

    In order for Type 1 fonts to be embedded into a document, the Type 1 font file (*.pfb) needs to be in the same directory as the font metrics file (*.afm). If only the font metrics file is available, the document can be created with the font, but the computer used to view the document needs to have the font installed. Type 1 fonts only support single-byte encoding.

  • TrueType fonts (*.ttf) and TrueType font collections (*.ttc)

    Embedding TrueType fonts and TrueType font collections is optional. When a TrueType font is embedded, only the portions of the font needed to represent the data are embedded. The list of available character set encodings is retrieved from the font file. In addition to the retrieved encodings, the multilingual "Identity-H" encoding can be used. When this encoding is used, the font is always embedded into the document. You can embed TrueType fonts, which support double-byte character sets, as an alternative to the Adobe Asian fonts. This generates a larger document, but the computer used to view it does not need to have the font installed.

    Run SQL supports building PDF documents with bi-directional data, if the locale of the current request is Hebrew or Arabic.

Start of changeOpenDocument Spreadsheet (.ods)End of change
Start of changeThe OpenDocument spreadsheet documents created by iSeries Access for Web conform to the Oasis Open Document Format for Office Applications (OpenDocument) 1.0 specification.

Date and time values are stored in date and time format only if the ISO date and time format options are chosen. Otherwise, they are stored as text values.

End of change
Run SQL: Prompted statements
Run SQL supports SQL statements containing parameter markers. There are two ways to create this type of statement. The first option is through the SQL Wizard. The SQL Wizard supports parameter markers for condition values. In addition to the option of specifying the condition values as part of the request, the SQL wizard provides the option to prompt for condition values when the request is run. The SQL wizard handles building the page to prompt for the condition values as well as building the SQL statement containing parameter markers.

The second way to create an SQL statement with parameter markers is to manually enter the statement using Run SQL. This option requires the request to be saved. The request cannot be run directly from Run SQL or with the Run link from My Requests. The Run SQL Request (iWADbExec) URL interface must be used to pass values for the parameter markers. One URL parameter must be specified for each parameter marker in the statement. The URL parameters must be named iwaparm_x, where x is the parameter index. iwaparm_1 is used for the first parameter marker, iwaparm_2 is used for the second parameter marker, and so on. For example:

  http://server:port/webaccess/iWADbExec?request=promptedRequest&iwaparm_1=Johnson&iwaparm_2=500

One way to invoke the Run SQL Request (iWADbExec) URL interface to pass values for parameter markers is to use an HTML form. Input fields can be used to prompt the user for the values. The names of these fields must follow the URL parameter naming convention mentioned above. The request name can be stored in the form as a hidden parameter. The form action must specify the Run SQL Request (iWADbExec) URI. When the form is submitted, the URL is built with the values specified, iSeries Access for Web is invoked, and the request is executed. Sample HTML source is shown below:

<HTML>
 <BODY>
  <FORM action="http://server:port/webaccess/iWADbExec" method="get">
   Enter a customer name and press <B>OK</b> to retrieve account information.<br>
   <input type="text" name="iwaparm_1" value=""/>
   <input type="submit" name="ok" value=" OK "/>
   <input type="hidden" name="request" value="promptedRequest"/>
  </FORM>
 </BODY>
</HTML>
Copy data to table
If you are copying data to a table, and the chosen file type is Extensible Markup Language (XML), the file to copy must be in a concise format. This format might or might not contain an embedded schema element and its supporting elements. In its simplest form, the XML document must be structured as shown below.
<?xml version="1.0" encoding="utf-8" ?>
<QiwaResultSet  version="1.0">
   <RowSet>
      <Row number="1">
         <Column1 name="FNAME">Jane</Column1>
         <Column2 name="BALANCE">100.25</Column2>
      </Row>
      <Row number="2">
         <Column1 name="FNAME">John</Column1>
         <Column2 name="BALANCE">200.00</Column2>
      </Row>
   </RowSet>
</QiwaResultSet>

This format consists of the XML directive, followed by the root element QiwaResultSet. If the encoding attribute is not specified in the XML directive, copy data to table will assume the document is encoded in utf-8. The root element contains a version attribute. The version corresponding to this format of XML is 1.0. The RowSet element is a container for all the rows of data that follow. These rows of data are contained within Row elements. Each Row element must have a unique numeric number attribute. Within each Row element is one or more Column elements. Each column element within a row must be unique. This is accomplished by adding a sequential numeric suffix. For example, Column1, Column2, Column3, Columnx, where 'x' is the number of columns in the row. Each column must also have a name attribute. The name corresponds to the column name in the relational table on the server. If this simple format is used, the 'Validate document with its schema' setting must be turned off since the document does not contain a schema.

Although not required, an XML Schema may also be included in the document. Examine an XML document generated by Run SQL to get an idea of how a schema is structured. Also, visit the World Wide Web Consortium's Web site for additional information about XML schemas.

Start of changeImport QueryEnd of change
Start of changeQuery files can contain much more information in them than just the SQL statement. Since Run SQL function stores only the SQL statement, some considerations need to be made to get identical query results. In cases where the Query file contains special instructions for the query, you might need to use the Customize function to create a new iSeries Access for Web database connection to honor the special case. Default iSeries Access for Web database connections will run database query requests using SQL naming conventions and using the locale specific defaults for the current user profile. Known special cases requiring the creation of non-default database connections, with the special attributes set, are:
  • System naming convention is used for the table designation
  • Date and time formats other than locale defaults are specified in the query
  • Decimal separator character other than the locale default is used in the query
  • A non-default sort sequence is specified
iSeries Access for Web cannot determine the CCSID of the contents of the query file. If the user profile that is importing the query has a CCSID that does not match the CCSID of the data in the query file, incorrect conversions or conversion errors might result. Users can set a CCSID value during the import of the query to overcome this problem.End of change
Related reference
Customize
Related information
IBM Toolbox for Java JDBC properties