Vulcan runtime, DBFCDX order seek failure on customers machine
Posted: Thu Nov 08, 2018 9:24 am
Gerhard,
No need to change that. We will not change that behavior in the VO SDK classes.
I commented about that, because experience shows that many people simply ignore these return values. Converting the code to throw exceptions in stead would make that impossible, and is something that should be done in new code.
In fact inside our RDD system we are already doing that.
The old (Clipper - VO - Vulcan) code was returning success or failure from the RDD layer to the runtime in a similar way. That mean that a property such as EOF had to be read by the runtime by passing a logical value by reference to a method in the RDD. The return value of the method indicated success or failure and on success the value by reference would return the EOF state.
We have changed this now. EOF is a property of the RDD. When a problem happens then the RDD will throw an exception.
That makes the interface of the RDD somewhat easier.
Of course we now have to catch the exceptions in a layer inside the runtime, because in the end the functions such as DbGoTop() still need to return TRUE or FALSE.
If you look into the docs for the CoreDb.Eof() method you will see this
https://github.com/X-Sharp/XSharpPublic ... CoreDb.prg
The method on line 555 looks like this:
- The code inside the CoreDb() call is a multi line lambda expression (a kind of codeblock on steroids, sometimes called an unnamed function)
- The CoreDb.CWA method returns the current workarea as an IRDD interface. It also clears the LastRDDError property in the runtimestate and throws an exception when there is no table open in the current workarea.
- We are returning the EOF property of that interface
- The CoreDb.Do construct around it is a convenient way to wrap this code with a generic protocol to have a try catch and store the exception in a common location. It uses some new mechanism in .Net. This method looks like this:
This is a generic method that will return a type T. The Type is determined by the return type of the code that gets passed in the action parameter. In this case the action is oRDD:EOF so the return type is Logic.
If an exception occurs then the exception is stored in the Runtimestate and an empty LOGIC (false) is returned.
If you look in this source you will see that most of the RDD methods are encapsulated in a call to CoreDb.Do() to standardize the error handling.
In short:
There is no need to change anything in your code.
Robert
PS Sorry for the long answer. It was a nice excuse to explain some of what we have done in the RDD system. Maybe Wolfgang can add some of this to his docs ?
No need to change that. We will not change that behavior in the VO SDK classes.
I commented about that, because experience shows that many people simply ignore these return values. Converting the code to throw exceptions in stead would make that impossible, and is something that should be done in new code.
In fact inside our RDD system we are already doing that.
The old (Clipper - VO - Vulcan) code was returning success or failure from the RDD layer to the runtime in a similar way. That mean that a property such as EOF had to be read by the runtime by passing a logical value by reference to a method in the RDD. The return value of the method indicated success or failure and on success the value by reference would return the EOF state.
We have changed this now. EOF is a property of the RDD. When a problem happens then the RDD will throw an exception.
That makes the interface of the RDD somewhat easier.
Of course we now have to catch the exceptions in a layer inside the runtime, because in the end the functions such as DbGoTop() still need to return TRUE or FALSE.
If you look into the docs for the CoreDb.Eof() method you will see this
https://github.com/X-Sharp/XSharpPublic ... CoreDb.prg
The method on line 555 looks like this:
Code: Select all
STATIC METHOD Eof() AS LOGIC
RETURN CoreDb.Do ({ =>
LOCAL oRDD := CoreDb.CWA(__FUNCTION__) AS IRDD
RETURN oRDD:EoF
})- The CoreDb.CWA method returns the current workarea as an IRDD interface. It also clears the LastRDDError property in the runtimestate and throws an exception when there is no table open in the current workarea.
- We are returning the EOF property of that interface
- The CoreDb.Do construct around it is a convenient way to wrap this code with a generic protocol to have a try catch and store the exception in a common location. It uses some new mechanism in .Net. This method looks like this:
Code: Select all
INTERNAL STATIC METHOD Do<T>(action AS @@func<t>) AS T
TRY
RETURN action()
CATCH e AS RddError
RuntimeState.LastRDDError := e
END TRY
RETURN DEFAULT(T)
If an exception occurs then the exception is stored in the Runtimestate and an empty LOGIC (false) is returned.
If you look in this source you will see that most of the RDD methods are encapsulated in a call to CoreDb.Do() to standardize the error handling.
In short:
There is no need to change anything in your code.
Robert
PS Sorry for the long answer. It was a nice excuse to explain some of what we have done in the RDD system. Maybe Wolfgang can add some of this to his docs ?