OpenEdge Data Management: DataServer for Microsoft SQL Server

Initial Programming Considerations
2–46
If you use NO–ERROR to do your own error handling, you must account for the fact that a MS SQL
Server data source creates or updates a record later than an OpenEdge database does. For
example, the following code does not trap data source errors, because the requests to perform
the operations have not yet been sent to the data source:
CREATE customer NO-ERROR.
ASSIGN customer.custnum = 45 NO-ERROR.
ASSIGN customer.name = "Smith" NO-ERROR.
The VALIDATE statement causes the DataServer to send requests to your MS SQL Server data
source, so incorporate it into your error-handling technique, as in the following example:
DEFINE VAR jx AS INTEGER.
DO TRANSACTION:
CREATE customer NO-ERROR.
ASSIGN customer.custnum = 45 NO-ERROR.
VALIDATE customer.
IF ERROR-STATUS:ERROR THEN DO:
MESSAGE "error: number of messages = " ERROR-STATUS:NUM-MESSAGES.
DO jx = 1 TO ERROR-STATUS:NUM-MESSAGES:
MESSAGE "error" ERROR-STATUS:GET-NUMBER(j)
ERROR-STATUS:GET-MESSAGE (jx).
END.
UNDO, LEAVE.
END.
ASSIGN customer.name = "Smith" NO-ERROR.
VALIDATE customer.
IF ERROR-STATUS:ERROR THEN . . .
END.
This code returns data-source errors after the VALIDATE statement.
The
DataServer
prompts for
the customer
number.
Another difference in behavior occurs when two users simultaneously attempt to create records
with duplicate OpenEdge keys. An OpenEdge database raises an error immediately, but the data
source raises an error after the first transaction commits and only if the second transaction does
not roll back. To avoid this difference, either change the scope of the transaction so that it
completes more quickly or make the key nonunique and enforce uniqueness at the application
level. Another technique is to use a RELEASE or VALIDATE statement when you check for the
key’s uniqueness.