O4W Wrinkles

We've recently been having fun in Sprezz Towers creating an O4W app and we've been very impressed with just how much we can achieve without cutting any code. In some ways it feels a bit like the old days of R/Design with Rev G. Because we saw it in that way we had certain expectations as to how the deployed product would work which we expect most other developers will share. Our testing revealed that some of these expectations were not being met and after a series of discussions with the team at Revelation we've decided to outline what we found and to describe the workarounds and fixes that can be done and will be made available. Hopefully this will prevent other developers from falling into the same trap!

Our first expectation was related to OConvs and Iconvs on a dictionary item.

From this screen shot you'd probably assume that if the user entered say "31 Feb 2012" into the field and O4W was told to save it, it would refuse and display an error message. But in fact if you did that, not only would O4W not complain - it would actually insert "31 Feb 2012" into the database. The key here is the "Input Validation" prompt. If you don't tell O4W to validate something it won't just default back to the dictionary validation - it just won't validate.

We were surprised by this so Revelation have provided a work around in 9.3.1. If you add a PREWRITE event to your commuter program you can check the contents of a variable called STATMSG@ and if this contains anything it means that one or more of the conversions have failed. You can then simply return 0 from the commuter to cancel the save and display an error message.

   if STATMSG@ <> "" then
       * Error occurred in ICONV – abort the write
       * statMsg@ is already set, so the user will see what caused the error…
      retVal = 0
   end  else
      retVal = 1
   end

return retVal

Revelation are going to go one step further in the next major release and allow the developer to specify that the validation is against the dictionary so we won't need to cut ANY code.

The next surprise came when we set up the system in such a way that the write failed. This could be for physical reasons (say out of disk space) or logical reasons (write denied by security MFS). We expected to be told about this by an error message. Instead O4W assured us that the row was written to disk. It failed silently. Revelation have acted very quickly to fix this and 9.3.1 contains a patch which displays a message if the row cannot be saved..

So to summarise, if you're developing in current versions of O4W don't expect it to automatically validate your data nor to report back on a failed write until you upgrade to 9.3.1.