| |
| |
| |
| |
The RDBMSResolver component creates an XML packet that can be sent to an external data source (such as ASP/JSP page, servlet, and so on). The XML packet can easily be translated into SQL statements that can be used to update any standard SQL relational database
Note: You can use the RDBMSResolver component to send data updates to any external data source that can parse XML and generate SQL statements against a database —for example, an ASP page, a Java servlet, or a ColdFusion component.
The RDBMSResolver component works only with Flash Player 7.
The following are the RDBMSResolver component parameters:
tableName The table name put in the XML for the DB table that should be updated. This should be the same as the value input for any fieldInfo items (or they should be blank) for any fields that should be updated.
updateMode This parameter has several values that determine the way key fields are identified when the XML update packet is being generated, as follows:
umUsingAll: This setting uses the old values of all of the fields within the FxDataset to identify the record to be updated. This is the safest approach to updating, because it lets you guarantee that another user has not modified the record since you retrieved it. However, this approach is more time-consuming and generates a larger update packet. umUsingModified: This setting uses the old values of all of the fields that were modified within the FxDataset to identify the record to be updated. This method lets you guarantee that another user has not modified the same fields in the record since you retrieved it. umUsingKey: This is the default value for this parameter. This setting uses the old value of the key fields within the FxDataset. This implies an optimistic concurrency model, which most database systems today employ. This method guarantees that you are modifying the same record that you retrieved from the database. Your changes overwrite any other user's changes to the same data. nullValue The value put in a field's value to indicate a null value. This is customizable to prevent it from being confused with an empty string ("") or another valid value.
fieldInfo If your data source is a database table, then it should have one or more key fields that uniquely identify a record within a table. Additionally, there may be fields that have been calculated or joined from another table. Those fields must be identified so that key fields can be set within the XML update packet, and fields that should not be updated are left out of the XML update packet.
The RDBMSResolver component provides a fieldInfo parameter for this purpose. This parameter allows you to define an unlimited number of fields that require special handling. Each fieldInfo item contains three properties:
fieldName: Name of a field. This should map to a field in the data set.ownerName (optional): This is used to identify fields that are not "owned" by the same table that is defined in the component TableName parameter. If this is filled in with the same value as that parameter or left blank, then the field is included normally in the XML update packet. If filled in differently, then this field is left out of the update packet.isKey: A Boolean value that should be set to true for all key fields for the table that will be updated.
The following example identifies the key fields in the customer table. The customer table has a single key field, "id", so you should create a fieldInfo item with the following values:
fieldName = "id", ownerName = leave this value blank, isKey = "true"
As a further example, suppose a field "custType" was added via a join in the query, and you don't want that field included in the update. You can create a field item with the following values:
fieldName = "custType", ownerName = "joinedField", isKey = "false"
Once the field items are defined, the RDBMSResolver component can use them to automatically generate the XML update packet to be sent to your external data source.
Note: The FieldInfo parameter makes use of a feature in Flash called the Collection Editor. When you select the FieldInfo parameter, the Collection Editor dialog box opens. From here you can add new FieldInfo items and set their fieldName, ownerName, and isKey properties from one location.
The typical workflow for the RDBMSResolver component is as follows.
To use an RDBMSResolver component:Note: The web service must return an array of records to be bound to the data set.
Note: The update instructions are sent from the DataSet component to the RDBMSResolver component when the applyUpdates method of the DataSet component is called.
Note: In addition to these steps, you an also create bindings to apply the result packet sent back from the server to the DataSet component via the RDBMSResolver component.
For more information, see RDBMSResolver component.
The XML update packet contains three different types of nodes: delete, insert, and update. Each of these nodes represents a change to a row in a database table. Each node contains field nodes that locate a record to update and describe the modifications made, if any.
The updates sent from a resolver component are in the form of an XML update packet that is sent to an external data source via a connector component. The following is an example of an RDBMSResolver component's XML update packet generated with updateMode parameter set to umUsingKey:
<update_packet tableName="customers" nullValue="{_NULL_}" transID="46386292065:Wed Jun 25 15:52:34 GMT-0700 2003">
<delete id="11295627477">
<field name="id" type="numeric" oldValue="10" key="true"/>
</delete>
<insert id="12345678901">
<field name="id" type="numeric" newValue="20" key="true"/>
<field name="firstName" type="string" newValue="Davey" key="false"/>
<field name="lastName" type="string" newValue="Jones" key="false"/>
</insert>
<update id="98765432101"> <field name="id" type="numeric" oldValue="30" key="true"/>
<field name="firstName" type="string" oldValue="Peter" newValue="Mickey" key="false"/>
<field name="lastName" type="string" oldValue="Tork" newValue="Dolenz" key="false"/>
</update>
</update_packet>
Elements in the XML update packet include the following:
transID: An ID generated by the DeltaPacket that uniquely identifies this transaction. This information should accompany the results packet returned to this component.delete: This type of node contains information about a row that was deleted.insert: This type of node contains information about a row that was added.update: This type of node contains information about a row that was modified. id: A number that uniquely identifies the operation within the transaction. This information should accompany the results packet returned to this component.newValue: This attribute contains the new value for a field that was modified. It appears only when the field value has changed.key: This attribute is true if the field should be used to locate the row to update. This value is determined by the combination of the RDBMSResolver component's updateMode parameter, the fieldInfo.isKey setting, and the type of operation (insert, delete, update).The following table describes how the key attributes value is determined. If a field is defined as a key field, using the RDBMSResolver component's fieldInfo parameter, it will always appear in the update packet with key="true". Otherwise, the field's key attribute in the update packet will be set according to the following table:
|
Node type |
umUsingKey |
umUsingModified |
umUsingAll |
|---|---|---|---|
|
delete |
|
|
|
|
insert |
|
|
|
|
update |
|
|
|
Once the server has finished with the update packet, either successfully or unsuccessfully, it should send back a result packet containing errors or additional updates resulting from the update operation. If there are no messages, the results packet should still be sent, but it will have no operation result nodes.
The following is a sample RDBMSResolver component results packet (with both update results and change information nodes):
<results_packet nullValue="{_NULL_}" transID="46386292065:Wed Jun 25 15:52:34 GMT-0700 2003">
<operation op="delete" id="11295627479" msg="The record could not be found"/>
<delete>
<field name="id" oldValue="1000" key="true" />
</delete>
<insert>
<field name="id" newValue="20"/>
<field name="firstName" newValue="Davey"/>
<field name="lastName" newValue="Jones"/>
</insert>
<operation op="update" id="02938027477" msg="Couldn't update employee.">
<field name="id" curValue="105" msg="Invalid field value" />
</operation>
<update>
<field name="id" oldValue="30" newValue="30" key="true" />
<field name="firstName" oldValue="Peter" newValue="Mickey"/>
<field name="lastName" oldValue="Tork" newValue="Dolenz"/>
</update>
</results_packet>
The results packet contains four different types of nodes:
Operation nodes contain the result of operations from the update packet. Each operation node should have the following attributes/child nodes:
op: An attribute describing the type of operation that was attempted. Must be insert, delete, or update.id: An attribute that holds the ID from the operation node that was sent outmsg (optional): An attribute containing a message string that describes the problem that occurred when attempting the operationfield: 0, 1, or more child nodes that give field-level specific information. Each field node, at a minimum, should have a name attribute that contains the field name, and a msg attribute that gives the field-level message. It may also optionally contain a curValue attribute that holds the most up-to-date value for that field in that row on the server.Update nodes contain information about records that have been modified since the client was last updated. Update nodes should have child nodes that list the fields that are necessary to uniquely identify the record that was deleted, and that describe fields that were modified. Each field node should have the following attributes:
name: Holds the name of the fieldoldValue: Holds the old value of the field before it was modified. This attribute is required only when the key attribute is included and set to true.newValue: Holds the new value that the field should be given. This attribute should not be included if the field was not modified (i.e., the field has been included in the list only because it is a key field).key: Holds a Boolean true or false value that determines whether or not this field will be used as a key to locate the corresponding record on the client. This attribute should be included and set to true for all key fields. It is optional for all others.Delete nodes contain information about records that have been deleted since the client was last updated. Delete nodes should have child nodes that list the fields that are necessary to uniquely identify the record that was deleted. Each field node must have a name attribute, an oldValue attribute, and a key attribute whose value is set to true.Insert nodes contain information about records that have been added since the client was last updated. Insert nodes should have child nodes that describe the field values that were set when the record was added. Each field node must have a name attribute and a newValue attribute. | |
| |
| |
| |