Products Services Download
  Support Contact Purchase
 

Delivering data   —   where and when you need it

   > Schema  > Products  > SRTransport  > Documentation  > Solutions  > Rejects
 

  Reprocessing Rejects

Reprocessing Rejects in an SR·Agent Script

There are many different reasons why rows would be rejected during a transport. Here are some possibilities:

  • referential integrity is violated
  • the row doesn't pass business validation, either within the transport or in database rules
  • the row was corrupt in the file
  • out of disk space
  • the database or fileserver became unavailable (crashed)

Some problems that cause rejected records require manual intervention. Other problems can be handled within the script. Here is an example script which attempts to fix a referential integrity problem and then re-runs the rejected records.

The script assumes that most rejects are caused by invalid ship_codes in the invoice.data file. Most often, you know what errors are common from direct experience, especially if a transport is run regularly.

The script handles these errors by creating any missing ship_code records (the records are marked as being automatically created), and then re-transporting the rejected records. For example, we may be transporting old invoices with ship_codes that are not in our current ship_codes.

   #!/bin/sh

   srtransport invoice.transport SOURCE invoice.data \
                TARGET -password ""

   # if there are any rejected records...
   if [ ! -z invoice.reject ]; then
      mv invoice.reject invoice.reject.data

      # insert any missing ship_codes
      srtransport -t invoice_ship_codes.transport \
         SOURCE invoice.reject.data \
         DEST -password [password]

      # retry the rejected records, hoping that the newly inserted
      # ship_codes will allow some of these rejects to be transported
      srtransport invoice.transport \
         SOURCE invoice.reject.data \
         DEST -password [password]

      # any records rejected here, are rejected for different reasons
   fi
Schema Research Corporation webmaster