Adding Data to a Dataset [ Getting Started With TRANSACT V ] MPE/iX 5.0 Documentation
Getting Started With TRANSACT V
Adding Data to a Dataset
This first program adds new customers to the customer set.
_________________________________________
| |
| 1 system ex8,base=orders(";");|
| 2 level; |
| 3 prompt cust-no: |
| name: |
| street-addr: |
| city-state: |
| zipcode; |
| 4 put customer; |
| 5 end; |
_________________________________________
Figure 2-1. Program to add data to a dataset
1 By including the database password (";" ) in the SYSTEM
statement, we avoid prompting the user for it.
2 The LEVEL verb sets up a looping structure which repeats whenever
the END verb is executed (line 5 in the example). Levels can be
nested, as we will see in later examples. What happens when the
END verb is executed is that Transact keeps track of the start of
the code identified by each LEVEL verb. Control returns to the
starting point of the current level whenever the END verb is
executed.
3 The PROMPT verb sets up data storage and prompts the user, one
data item at a time, to enter values for a new record. Transact
automatically generates entry text to identify each item as it
should be entered. By default, the prompt is the name of the
data item.
4 The PUT statement adds the record just entered to the customer
set.
_____________________________________
| |
| CUST-NO> 301 |
| NAME> Joe's Bike Shop |
| STREET-ADDR> 1243 East Julian |
| CITY-STATE> San Jose, Ca. |
| CUST-NO> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
_____________________________________
Figure 2-2. Interactive data entry to a dataset
The program repeats, or loops, indefinitely. When the last customer has
been added, The user stops the loop by entering the special character "]"
. This character is reserved in Transact to signify the end of user
interaction.
The program called for the zipcode to be entered, but we see that the
user was not prompted for it. The reason is not a bug in the program.
Instead, the comma entered between the city and state sent an unexpected
message to the Transact processor.
Transact allows user input to be stacked. That is, users who know what
the program is going to ask for can enter the data in advance. The
default field separator for Transact is the comma.
Thus our program did not work correctly. When we responded to the
CITY-STATE prompt, Transact associated San Jose with CITY-STATE and
associated CA. with ZIPCODE.
The following program gets around this problem by changing the default
field separator.
_________________________________________
| |
| 1 system ex9,base=orders(";");|
| 2 set(delimiter) "/"; |
| 3 level; |
| 4 prompt cust-no: |
| name: |
| street-addr: |
| city-state: |
| zipcode; |
| 5 put customer; |
| 6 end; |
_________________________________________
Figure 2-3. Changing the default input field delimiter
2 The SET(DELIMITER) statement makes the field separator a slash
rather than the comma.
An example of a terminal session is shown in Figure 2-4.
______________________________________________________________________
| |
| CUST-NO> 303 |
| NAME> John's Consulting |
| STREET-ADDR> 5489 El Camino |
| CITY-STATE> Santa Clara, Ca. |
| ZIPCODE> 95143 |
| CUST-NO> 304/The Flower Shop/123 1st Street/San Jose, Ca./95125|
| CUST-NO> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
______________________________________________________________________
Figure 2-4. Using a programmer-defined field delimiter
In the example above, we entered the data for the first customer one item
at a time. The data for the second customer was all entered on one line
by separating the fields with slashes. Note that Transact did not prompt
for the data items that were stacked.
Let's run the program again to see what happens if the customer already
exists.
__________________________________________________________________
| |
| CUST-NO> 301 |
| NAME> New name |
| STREET-ADDR> New street |
| CITY-STATE> New city |
| ZIPCODE> 123 |
| *ERROR:DUPLICATE KEY VALUE IN MASTER (IMAGE 43,7,CUSTOMER)|
| CUST-NO> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
__________________________________________________________________
Figure 2-5. Automatic error handling for a duplicate record
Transact provides us with an error message and restarts the Transaction
at the point of data entry. We can make the program more user friendly
by checking to see whether the customer exists before asking for the rest
of the customer data. Then if an error occurs, all the input will not
have to be entered a second time. The program now looks like this:
________________________________________________
| |
| 1 system ex10,base=orders(";"); |
| 2 set(delimiter) "/"; |
| 3 level; |
| 4 prompt cust-no,checknot=customer;|
| 5 prompt name: |
| street-addr: |
| city-state: |
| zipcode; |
| 6 put customer; |
| 7 end; |
________________________________________________
Figure 2-6. Program to check item entered by user
4 The CHECKNOT=CUSTOMER causes the cust-no input to be validated
against the customer dataset to verify that an entry does not
already exist. If an entry does exist, Transact provides an
error message and prompts for input of cust-no again.
This results in the following dialog when the program is run and the user
enters a customer number that already exists:
_________________________________________________________
| |
| CUST-NO> 301 |
| *ERROR: ENTRY ALREADY EXISTS (IMAGE 1,4,CUSTOMER)|
| CUST-NO> 306 |
| NAME> High Fashions |
| STREET-ADDR> 1 The Embarcadero |
| CITY-STATE> San Francisco, Ca. |
| ZIPCODE> 93245 |
| CUST-NO> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
_________________________________________________________
Figure 2-7. User interaction with early error checking
Updating data in a dataset
The programs that follow demonstrate three types of updating. These are
changing data for non-key items, changing data for key items, and
deleting records.
___________________________________________
| |
| 1 system ex11,base=orders(";"); |
| 2 set(delimiter) "/"; |
| 3 list(auto) customer; |
| 4 level; |
| 5 data cust-no,check=customer;|
| 6 set(key) list (customer); |
| 7 get customer; |
| 8 display; |
| 9 data(set) name: |
| street-addr: |
| city-state: |
| zipcode; |
| 10 update customer; |
| 11 end; |
___________________________________________
Figure 2-8. Program to update data in a dataset
3 LIST reserves space to hold the customer record. In the previous
example we let the PROMPT verb reserve space automatically as we
went along. LIST prepares a temporary storage area to receive
data. When LIST is used, DATA is used to prompt for data and
receive the input. In these simple programs, the two methods
produce the same result. For more complex data manipulation,
setting up the temporary area before prompting for data provides
more flexibility.
5 Since the space has already been reserved, we use the DATA verb
rather than the PROMPT verb. Since we are updating existing
records, we want to verify that the cust-no that is entered
already exists. If it does not exist, an error message is
generated and the prompt repeated. CHECK=CUSTOMER does this for
us.
6 SET(KEY) sets up the IMAGE key to be used to retrieve the
customer record.
8 DISPLAY displays the record. This gives the user a chance to see
if this is really the record he meant to update.
9 The SET option specifies that if the user presses [[RETURN]] in
response to any prompt, the original data for that item is
retained. If we did not use this option, then when the user
pressed [[RETURN]] the item would become spaces or zero,
depending on whether it was an alphanumeric or numeric item.
10 UPDATE moves the record into the customer set.
_____________________________________________________________________
| |
| CUST-NO> 305 |
| *ERROR: NO ENTRY FOUND (IMAGE 17,9,CUSTOMER) |
| CUST-NO> 301 |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE:|
| ZIPCODE: |
| 301 Joe's Bike Shop 1243 East Julian San Jose |
| Ca. |
| |
| NAME> |
| STREET-ADDR> |
| CITY-STATE> |
| ZIPCODE> 12345 |
| CUST-NO> 301 |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE:|
| ZIPCODE: |
| 301 Joe's Bike Shop 1243 East Julian San Jose |
| 12345 |
| |
| NAME> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
_____________________________________________________________________
Figure 2-9. Interactive updating of a dataset
Note that a valid cust-no has to be entered before the program will
continue.
In the above example, we corrected the zipcode, but left the other items
as they were.
When we enter the same customer number a second time, Transact displays
the updated record, thereby giving us an easy way to verify the data just
entered--or to further change the record if necessary.
In the next program, we take advantage of the fact that Transact has to
retrieve the customer record when it verifies cust-no. In fact, this
feature actually makes our program less complicated and eliminates an
extra database access.
____________________________________________
| |
| 1 system ex12,base=orders(";"); |
| 2 set(delimiter) "/"; |
| 3 list(auto) customer; |
| 4 level; |
| 5 data cust-no,check=customer;|
| 6 get(current) customer; |
| 7 display; |
| 8 data(set) name: |
| street-addr: |
| city-state: |
| zipcode; |
| 9 update customer; |
| 10 end; |
____________________________________________
Figure 2-10. Program using a record already retrieved
6 We know that Transact already retrieved the record in order to do
the validation check in step 5. Therefore, by using the CURRENT
option to get the record out of the temporary storage area, we
save both the physical time of retrieving the record a second
time and also simplify the program.
What if we need to change the cust-no to another value. Since this is a
key item to IMAGE, we have to treat it differently. One way is to delete
the old record and add a new. The next example shows this method.
_____________________________________________________________________
| |
| 1 system ex13,base=orders(";"); |
| 2 set(delimiter) "/"; |
| 3 list(auto) customer; |
| 4 level; |
| 5 data cust-no,check=customer; |
| 6 get(current) customer; |
| 7 display; |
| 8 delete(current) customer; |
| 9 data cust-no ("enter new cust-no"),checknot=customer;|
| 10 data(set) name: |
| street-addr: |
| city-state: |
| zipcode; |
| 11 put customer; |
| 12 end; |
_____________________________________________________________________
Figure 2-11. Program to change a key field value
8 The DELETE statement removes the old customer record.
9 This DATA statement overrides the default prompt for a data
field, substituting the prompt enter new cust-no. It also
verifies that this new customer does not already exist.
10 The temporary storage area still contains the values for the old
customer that we just deleted. The user may change any of these
values or leave them as is by pressing [[RETURN]] to any of the
prompts.
11 The new customer record is added to the dataset.
_______________________________________________________________________
| |
| CUST-NO> 301 |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE: |
| ZIPCODE: |
| 301 The Cannery 123 Worthy Street Waltham, Ma.|
| 46534 |
| enter new cust-no> 303 |
| *ERROR: ENTRY ALREADY EXISTS (IMAGE 1,16,CUSTOMER) |
| enter new cust-no> 302 |
| NAME> |
| STREET-ADDR> |
| CITY-STATE> |
| ZIPCODE> 46533 |
| |
| CUST-NO> 302 |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE: |
| ZIPCODE: |
| 302 The Cannery 123 Worthy Street Waltham, Ma.|
| 46533 |
| enter new cust-no> 301 |
| NAME> |
| STREET-ADDR> |
| CITY-STATE> |
| ZIPCODE> |
| |
| CUST-NO> ] |
| EXIT/RESTART(E/R)?> |
| END OF PROGRAM |
| : |
_______________________________________________________________________
Figure 2-12. Changing a key field value
Most of the time this program works correctly. However, if a problem
like a system crash occurs immediately after the delete of the old
customer and just before the add of the new customer, we force the user
to add the complete customer record after system recovery.
We could modify this program to first add the new customer and then
delete the old, but to do this would require setting up a data item
within the program to hold the value of the old cust-no while we added
the new one. We may do this in a later example, but another way to do
this is to use the special verb REPLACE, which does the hard work for us.
The following program shows how to use REPLACE to update a key field.
__________________________________________________________
| |
| 1 system ex14,base=orders(";"); |
| 2 set(delimiter) "/"; |
| 3 list(auto) customer; |
| 4 level; |
| 5 data(key) cust-no ("enter old cust-no"); |
| 6 get customer; |
| 7 display; |
| 8 data(update) cust-no ("enter new cust-no")|
| ,checknot=customer; |
| 9 replace customer; |
| 10 end; |
__________________________________________________________
Figure 2-13. Program to change key values using REPLACE
5 The KEY option automatically sets up the IMAGE key, preparing us
to retrieve the customer record. When the KEY option can be
used, the DATA verb performs the input of data and also sets the
IMAGE key for database retrieval. Note that we are also
supplying our own prompt.
8 DATA(UPDATE) tells Transact that we really do want to change a
key field in the record. CHECKNOT verifies that the new customer
number does not already exist in the dataset.
9 REPLACE causes the new customer record to be added before the old
customer record is deleted.
In this example, we did not allow any other fields to be updated. We
could have, by prompting with DATA(UPDATE) for each of the fields. In
other words, when you use the REPLACE verb, you must give Transact the
new values, using DATA(UPDATE) or its equivalent. Any data items not
specified this way, retain the values from the original record.
Figure 2-11 used the DELETE verb to change a key value. Figure 2-14 is
an example of a program that uses the DELETE verb to simply delete
records.
______________________________________________________________
| |
| 1 system ex15,base=orders(";"); |
| 2 list(auto) customer; |
| 3 level; |
| 4 data(key) cust-no ("enter cust-no to delete");|
| 5 get customer; |
| 6 display; |
| 7 input "delete this customer?"; |
| 8 if input = "Y","YES" |
| 9 then delete(current) customer |
| 10 else display "customer not deleted"; |
| 11 end; |
______________________________________________________________
Figure 2-14. Program to delete records
7 The INPUT verb is used to get a value from the user that is to be
tested by an IF statement. Here it gets verification from the
user that this is the customer to delete.
8 Whatever the user types in as a response to the INPUT verb is
automatically upshifted. Thus we check to see if the response is
y or yes. If so, the customer is deleted. If not, we print a
confirmation that nothing was done.
_______________________________________________________________________
| |
| enter cust-no to delete> 301 |
| |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE: |
| ZIPCODE: |
| 301 The Cannery 123 Worthy Street Waltham, Ma.|
| 46533 |
| |
| delete this customer? n |
| customer not deleted |
| |
| enter cust-no to delete> 301 |
| |
| CUST-NO: NAME: STREET-ADDR: CITY-STATE: |
| ZIPCODE: |
| 301 The Cannery 123 Worthy Street Waltham, Ma.|
| 46533 |
| |
| delete this customer? y |
| |
| enter cust-no to delete> 301 |
| |
| *ERROR: NO ENTRY FOUND (IMAGE 17,10,CUSTOMER) |
| |
| enter cust-no to delete> ] |
_______________________________________________________________________
Figure 2-15. Interactively deleting records
MPE/iX 5.0 Documentation