Haha yeah. Because that's never happened where a vendor changes something that breaks your code. Live with it and work out how to fix it. Sage don't have a crystal ball. They can never guarantee that a change they make will never break your stuff. I'd never have created an entity with a 3 letter prefix followed by 2 underscores. Internally that underscore could easily be used in a split() function and using 2 would break that. Although it would be quite an arduous job changing the entity prefix to something like xjob would be possible with some sql updates and good sql scripting and using something like notepad++ to search all files for a double underscore. Sage have no obligation to fix your code or customisations.

Hi Graham

The rules around field naming would have been tightened because of the requirements of XML. As web services became more important it became a necessity that fields must adhere to the standards. When the SOAP interface was introduced Sage created element names by removing the column name prefixes and that meant that certain characters immediately following the prefix became illegal.

Thanks very much for the reply. It is helpful to know a bit of the background. We all agree that the product needs to evolve over time to support new technologies. And certainly adding web services was a necessary enhancement.

Even so, now that it’s been added, today’s product manager(s) had – and still have – different options in terms of how to implement the requirements in the CRM Administrator program, i.e. when a user adds a new field to a custom table. The two most obvious models are:

• current model: do not allow any new fields to be added that do not conform to the XML requirements (an "all-or-nothing approach")
  
  
• alternative model: allow such fields to be added but warn the CRM Admin that adding such a field will render the table unavailable to the SOAP interface (a "flexible approach")

If Sage CRM were a brand new product being designed today, then the current model would make perfect sense. It would ensure that all custom fields conform to the XML requirements.

But Sage CRM is a mature product. It’s been in the marketplace for some two decades, with thousands of installs and countless customizations. So the more flexible approach that doesn’t risk arbitrarily "dead ending" even a small number of customizations – that is the better model for Sage CRM today.

One final note is that tweaking the validation logic for adding a new field, so that the UI merely warns the user – surely this is a simple change to implement. And so, as I say, hopefully Sage can and will fix this in a Patch release soon.