This build adds support for MEMOs and BLOBS to service methods. Support
is automatic, but may impact services by adding fields which were not
available before. As always, clients that ignore these fields will not
be a problem.
This build adds support for automatic formatting
parameter and return fields.
This feature can be activated
. (It is on by default.)
It can be overridden at the
in the Method.
Because this is a change,
which is on by default, it will almost certainly change the output
from your API. If you have custom clients using your API, you will
either need to update those, or turn this feature in the method off.
Please review your setup carefully to decide which approach to take.
all fields which are
stored as "not String" and have a picture, are automatically converted to strings (using
the picture) and vice-versa. Note that this applies to numeric fields
which have a picture that formats the number with , separators. (eg
1,234.56). Your client program may not be able to accept numbers
formatted in this way, so you may want to adjust the picture for
For Parameters this feature is limited
to parameter types TABLE, DATE, TIME, NUMBER and STRING.
GROUP, QUEUE, STRINGTHEORY and FILE are not supported.
For Return values this feature is
limited to FIELD (from the dictionary, not local data), TABLE and
VIEW return types. For VIEWs only Generated View fields are done
Embed points exist for both XML and JSON
which allow you to format, and deformat fields in hand-code.
Self.CurrentField = Deformat(pString,'@d6')|
For disconnected sync the server, and the desktop need to be
speaking the same language. For this reason the Desktop Sync client
now defaults to auto formatting. If you disable auto formatting on
the server side, then it needs to be disabled on the Desktop Client
so it is recommended that sync methods leave auto formatting on.
Field prefixes are a thorny problem for a couple of reasons.
Firstly, they're a foreign concept in most languages, so they are
often not desirable in a public API at all. Secondly they make use
of a colon separator, which is not a valid character in a variable
name in most languages.
For this reason you have the option
to include, or exclude prefixes from parameters and return values.
In most cases having the prefix OFF seems the better option.
For builds prior to 9.17 the default for prefixes was ON. For
parameters and values added using 9.17 or later the default value is
OFF. the setting for existing parameters and returns are not changed
by the update, however support for the prefix support in the system
has been overhauled so definitely check that your
methods are still working the way you expect.
writing a web app, colons are translated into a double underscore to
make the names compatible with HTML. For
ServiceMethods though, colons are translated into a single
underscore. In builds 9.16 and earlier this was slightly
inconsistent as simple GET and POST calls still made use of the
double underscore, where XML and JSON used a single underscore. From
9.17 this has been made consistent so that all requests, and all
responses use a single underscore if prefixes are ON.
Earlier builds did not reset the XML object back to native state between uses in the method.
This is a problem when the same object is used for multiple parameters, or parameters and return values.
Each use of the object is now prefixed with a call to the START method, which returns the object back to original state.
If you have set properties for the procedure before the START call then those settings are now lost.