OnRefindRecordError - cWebWidget

Sent when any refind DDO record operation fails

Type: Event

Parameters

Parameter	Type	Description
hoDD	Handle	This is the DDO that had the refind failure. This failed because RowId record no longer exists, is SQL filtered, or the RowId record is not constraint valid.
eOperation	Integer	ConstantMeaning
eReason	Integer	ConstantMeaning

Syntax

Procedure OnRefindRecordError Handle hoDD Integer eOperation Integer eReason

Description

This is sent when a refind record fails during one of the refind records operation. By default, it does nothing, but it can raise an error and allows for careful customization.

This event uses the cWebApp class pbShowAllRefindErrors property to determine if an unhandled error should be raised. When set to True, this event will display an error message. This is primarily used when debugging. Often setting pbShowAllRefindErrors is the first place to start when tracking down these kinds of issues.

All refind record errors go through this event. OnRefindRecordError is a good place to put a breakpoint to make sure that those refind errors are expected and not bugs. If you debug into OnRefindRecordError, you can look at the passed parameters to find out more about the source of the error.

This can be augmented, but be careful. In particular a reoSyncDDOs operation error causes this to be called during a low level request DataDictionary Obect (DDO) synchronization - there is not much you can do here.

Understanding Refind Record Errors

At various places the framework must refind existing records by their RowId. It uses the FindByRowIdEx function or the private FindByRowIdExNoAutoFill for this. This can fail for expected reasons (e.g., multi-user changes, programmed data changes) and unexpected reasons (bugs - e.g., invalid constraints). The framework cannot distinguish if a refind failure is expect or unexpected. In either case it attempts to handle this as smoothly as possible.

The goals are:

1. When possible, automatically handle the error in a sensible manner.
2. If desired, raise an error, but provide a way to suppress this error (this should probably be the default, because in most cases, it is of no use to the end user). This is used mostly for debugging and testing.
3. When needed, provide a hook to custom handle the error.

These errors rarely occur - when they do, fixing them is hard. About the best thing to do is to just fail gracefully. Errors can occur during different operations:

SyncDDO

Every time a client makes a request back to the server application, all DDOs in the appropriate views must be resynchronized with the contents on client. This is referred to as the SyncDDO process.

It synchronizes the DDOs by refinding all DDO records by their row id. If a record cannot be found, a refind error occurs. Most typically this occurs in a multi user environment where a record has been deleted, moved or modified in such a way as to make it constraint invalid. When this happens, the framework will correct this as best it can. It is also possible that an error may occur because of a programming error (e.g., bad constraints, bad relationships, missing indexes). While the framework will attempt to handle this, you may need to know about this to correct the problem.

When a SyncDDO refind error occurs, OnSyncDDOsRefindError is called, which sends OnRefindRecordError.

Navigate Forward

The most likely navigate forward errors will be not able to refind a constrained parent or not being able to refind the main record. A third possible error is trying to navigate forward when a constrained parent does not exist. This might be a case of a deleted record or it may be a case of programming error (it is even possible that this might be deliberate, but let's start with the assumption that this is not allowed). This also is really the same case as failing to refind a constrained parent.

By default, these errors will reverse the navigate forward. By the time these errors are detected the processing is pretty deep and the view is active - so it must actually close this view. It can optionally present an error. It will close the view by sending NavigateCancel. This is done inside of OnNavigateForwardRefindError, which sends OnRefindRecordError.

Navigate Back

The most likely navigate back errors will be not able to refind a constrained parent or not being able to refind the main record. When a navigate back fails, you have a difficult situation. Somehow you need to go back, but the view you are going back to is not right. By default, a navigate back error will just do the best it can. If it is a main file that cannot be found, the view you come back to will either be cleared (if a zoom) or refreshed (if a select). In most cases, this will probably suffice. You can customize this within OnNavigateBackRefindError, which sends OnRefindRecordError.

RefreshRecord

The RefreshRecord method is used to refresh a view around the data in the main DDO. If this refind fails, the event OnRefindRecordError is called, which sends OnRefindRecordError.

pbShowAllRefindErrors

pbShowAllRefindErrors is a cWebApp class property that all web views acquire via delegation. OnRefindRecordError uses this property to determine if an unhandled error should be raised. While you would not want to do this in a deployed application this can be useful during debugging. By setting this True, OnRefindRecordError will raise an unhandled error. This lets you see the error stack in the debugger and allows you to debug the problem. The idea is that during debugging, refind errors should probably not be happening. If they occur you probably have a logic bug. If they do occur, you can set this property true to see what was going on. By looking at the call stack, you can see what is causing this problem. These kinds of bugs can be difficult to track down, but this gets you close to the source of the problem.