Note: The code accompanying this article is available for download here.

In part 1 and part 2 of my XML series, I introduced you to the basics of using RPG’s XML support. In this tip we begin to explore some of the challenges that you may face when processing commercial XML documents, and the support RPG offers to handle them.

Take a look at the snippet of an XML document below:

<ItemsXRef >
    <Header RefId="xxxxx" TimeStamp="2011-11-30T00:06:06.643Z">
        <to id="nnnnnn" name="nnnnnn"/>
        <from id="nnnn" name="A Company in Canada"/>
        <TransactionType>ItemXref</TransactionType>
    </Header>
    <Items>
        <SKU>
            <SKUID>10050322</SKUID>
            <UPC>6866261486</UPC>
            <WIN>30269675</WIN>
            <StatusCode>A</StatusCode>
        </SKU>
        <SKU>
               ... <snip> ...
        </SKU>
        

Normalization is the process of making sure that each datum is stored in the proper table. Storing data in the wrong place gives rise to anomalies, a fancy word for problems, and you have enough problems already. To make sense of normalized data requires that tables be joined. Do you know the methods to code a join with SQL and the advantages and disadvantages of each one?

Method 1: WHERE

When I first learned SQL, joining was done in the WHERE clause of the SELECT statement. Here’s an example.

select h.*, d.*
  from SalesOrderHeaders as h,
       SalesOrderLines   as d
 where 

In part 1 of this series, I discussed the row permissions portion of the new row and column access control (RCAC) security feature that was introduced in DB2 for i 7.2. In this tip, I will demonstrate how to use RCAC to hide sensitive information without hiding entire rows from a user.

To sum up the last tip, RCAC is beneficial for protecting an integral business asset: data. Row permissions allow a database administrator to limit the rows users can view or modify in a table by defining access rules. Permissions to access rows are generally based on user profile