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 
		and 
deformatting of 
			parameter and return fields. 
This feature can be activated 
			and deactivated 			
			globally. (It is on by default.) 
It can be overridden at the
			
			field level 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.
Specifically 
			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 
			these fields.
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 
			automatically. 
Embed points exist for both XML and JSON 
			which allow you to format, and deformat fields in hand-code.
			
				| Format | Type | Method | Code Example | 
				| xml | parameter | xml.AssignField | 
					Self.CurrentField = Deformat(pString,'@d6') | 
				| json | parameter | json.DeformatValue | 
					Return Deformat(pValue,'@d6') | 
				| xml | return value | xml.SaveCurrentFieldToXML | 
					self.FormatCurrentField('@d6') | 
				| json | return value | json.FormatValue | 
					pLiteralType 
					= json:string Return clip(left(format(pValue,'@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 
			as well.
Currently the JavaScript sync is always formatted, 
			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. 
When 
			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.