Here are some initial suggestions / comments (no particular priority):

  1. Standardize on capitalization in naming. For example classnames EX.example and Sample.Classes, and property names name and Location.
  2. Use singular for your classname, e.g. Class rather than Classes
  3. Use meaningful classnames, e.g. Sample.Employee rather than Sample.Classes
  4. Use meaningful method names. e.g. insert or Insert rather than hello
  5. Avoid namespace switching unless really necessary. Presumably in your case the Sample.Classes class is in the USER namespace and the EX.example is somewhere else (maybe you wrote it in your SAMPLES namespace).
  6. For a REST interface, consider returning results in a structured form, e.g. JSON.
  7. Make good use of indenting. Perhaps you already have done this and the post to DC has mangled it.
  8. Avoid using Z-commands, $Z-functions and $Z if non-Z equivalents are available. For example, SET $NAMESPACE="USER" instead of ZN "USER". Note that you can also preserve the current $NAMESPACE value using NEW $NAMESPACE which will automatically reinstate the value when the stack level is exited.

I hope this is a useful start.

Did you answer your own question here? If so, DC now allows you to add an Answer to your own, and even mark it as the accepted answer. But I have a followup question: did you determine whether your solution is "legal" (i.e. a quirk of Management Portal), or is it a bug and likely to get "fixed" in a future release (thus breaking your app)?

After Michael's post originally appeared on the intersystems-public-cache Google Group (as a result of the automatic crossposting being done by a username intersystems.dc) my colleague George James responded in the Google Group (GG). However, whatever mechanism the user intersystems.dc has set up for crossposting only handles the initial DC post, and nor does it feed GG responses back to DC. So I'm re-posting George's response here where I think it will get a wider audience.

George wrote:

It seems to me that your ixdLastName index might be usable as some kind of rainbow table to attack the data contained in the AES encrypted field.
 

If I were able to perform a chosen-plaintext attack then querying with like 'J%', then 'Ja%', then 'Jam%' would trivially discover where my name was in the database. 

 
Have you carried out a cryptographic analysis of the strength of this approach?  Logically it must be weaker than just AES on its own.  My question is how much weaker?