next »

[Tim B.]

Have passed this to support already, but thought I'd share this one here and see whether people consider this a problem or coding issue.

If I close a window using the Cancel action it automatically sets int_flag = TRUE.  If I then call a web service it will fail with either a TCP error or error -15553 (undocumented).

This is simple to fix - simply ensure int_flag is set to FALSE before calling any web service, but should the web service header function not initialize this along with the other variables or is it the responsibility of the programmer?  I'm not entirely sure, but seems wrong that a web service should start in a state in which it is guaranteed to fail.

[Reuben B.]

Have passed this to support already, but thought I'd share this one here and see whether people consider this a problem or coding issue.

If I close a window using the Cancel action it automatically sets int_flag = TRUE.  If I then call a web service it will fail with either a TCP error or error -15553 (undocumented).

This is simple to fix - simply ensure int_flag is set to FALSE before calling any web service, but should the web service header function not initialize this along with the other variables or is it the responsibility of the programmer?  I'm not entirely sure, but seems wrong that a web service should start in a state in which it is guaranteed to fail.

web services errors are documented in the web services documentation https://4js.com/techdocs/genero/gws/devel/DocRoot/User/WseComErrorCodes.html
(although admittedly not in the greatest level of detail)

I was taught many years ago to reset the int_flag as soon as possible after you exit the dialog.  It amazes me how much code I see where people don't do that and I can construct a situation where they enter the next dialog with int_flag set to TRUE.

So whilst I would initially consider it the programmers responsibility to clear the int_flag, consider this scenario...

FUNCTION get_data()
   OPTIONS SQL INTERRUPT ON
   FOREACH cursor INTO record.*
     IF int_flag THEN
        EXIT FOREACH
     END IF
   END FOREACH
END FUNCTION

... should get_data() set the int_flag to FALSE before the FOREACH, or is it the responsibility of the developer to set int_flag before get_data() is called.

I would code the first way and clear the int_flag inside the function before the FOREACH rather than relying on each and every call to get_data() to ensure the int_flag is cleared.  So you could probably create a strong argument that the generated web service function should set int_flag = FALSE.

Reuben

PS if you use DIALOG, it doesn't set the int_flag

[Tim B.]

Regarding to documentation, I didn't see anywhere that states that the int_flag should be set to FALSE, or that it has any effect on the web service.  I also didn't see anything in the demo client apps.

I hadn't actually noticed there are 2 different error message references in the docs.  I was just using the first.  Thanks for pointing this out.

It's no big problem (now), but at the time it took me several days to work out the conditions under which the service was failing, only to realise it was simple matter of closing a window.  We had SAP on the case checking their side of things, and had been examining TCP packets with Wireshark to try and find clues as to the cause of the problem.

If the web service header isn't going to set int_flag, then can the docs and demo apps be changed to make this clear?  Others may encouter the same issue in the future and may spend days - as we did - figuring it out.