Ken,

Can you be more specific about the non-printing characters? If you are serializing  data to XML, you need to be clear about whether you are correctly XML-escaping the characters, or whether you are actually receiving values that are not permitted in XML. Is it clear as to which of these problems you are running into?

My personal preference for SQL is to make use of %SQL.Statement to manage my actual SQL queries, as it allows for *very* flexible query definitions. (You can also use the older %Library.ResultSet classes, but I strongly prefer using the newer code in %SQL.Statement.)

I also like to wrap the underlying query in an API that abstracts out some of my search options, but still allows me to control exactly what is queried.

Here is a sample of a wrapped  query of this kind:

ClassMethod PersonSearch(
  Output pIDList As %Library.ListOfDataTypes,
  Output pHasMore As %Boolean,
  pHomeState As %String = "",
  pOfficeState As %String = "",
  pHasSpouse As %Boolean = "",
  pMaxRows As %Integer = 50) As %Status
{
  Set tStatus = $$$OK
  Try {
    Set pIDList = ##class(%Library.ListOfDataTypes).%New()
    Set pHasMore = 0
    // The selected columns and other clauses (e.g. ORDER BY) can also be affected by parameters
    Set tSQL = "SELECT ID FROM Sample.Person"
    Set tArguments = 0
    Set tWHERE = ""
    If (pHomeState '= "") {
      Set tWHERE = tWHERE _ $listbuild("Home_State = ?")
      Set tArguments = tArguments + 1
      Set tArguments(tArguments) = pHomeState
    }
    If (pOfficeState '= "") {
      Set tWHERE = tWHERE _ $listbuild("Office_State = ?")
      Set tArguments = tArguments + 1
      Set tArguments(tArguments) = pOfficeState
    }
    If (pHasSpouse '= "") {
      Set tWHERE = tWHERE _ $listbuild("Spouse IS " _ $select(''pHasSpouse: "NOT ", 1: "") _ "NULL")
    }
    If (tWHERE '= "") {
       Set tSQL = tSQL _ " WHERE " _ $listtostring(tWHERE," AND ")
    }
    Set tStatement = ##class(%SQL.Statement).%New()
    Set tStatus = tStatement.%Prepare(tSQL)
    If $$$ISERR(tStatus) {
      Quit
    }
    Set tRowCount = 0
    // Use tArguments... to allow the array to be pushed out into individual parameters
    Set tRS = tStatement.%Execute(tArguments...)
    While tRS.%Next() {
      If (pMaxRows) {
        If (tRowCount = pMaxRows)) {
          Set pHasMore = 1
          Quit
        }
        Else {
          Set tRowCount = tRowCount + 1
        }
      }
      // You can reference select columns by name, but can also use variants of Get to retrieve them -- I find the name to be easy to understand
      Do pIDList.Insert(tRS.ID)
    }
    // Check for SQL errors - 0 is all OK, 100 is no more rows
    If (tRS.%SQLCODE && (tRS.%SQLCODE '= 100)) {
      Set tStatus = $$$ERROR($$$SQLCode,tRS.%SQLCODE,tRS.%Message)
      Quit
    }
  }
   Catch ex {
    Set tStatus = ex.AsStatus()
  }
  Quit tStatus

A rather subtle point that I haven't seen discussed here is actually about how TSTART/TCOMMIT/TROLLBACK should be handled when triggering a TROLLBACK from code that may be part of a nested transaction. Given that a lot of the code I write may be called from various contexts and those calling contexts may already have open transactions, my preferred transaction pattern is as follows:

Method SaveSomething() As %Status {
  Set tStatus = $$$OK
  Set tInitTLevel = $TLevel
  Try {
    // Validate input before opening transaction so you can exit before incurring any major overhead
    TSTART
    // Do thing 1
    // Do thing 2
    // Check status or throw exception
    TCOMMIT
  }
  // Handle exception locally due to local cleanup needs
  Catch ex {
    Set tStatus = ex.AsStatus()
  }
  While ($TLevel > tInitTLevel) {
    // Only roll back one transaction level as you make it possible for the caller to decide whether the whole transaction should be rolled back
    TRollback 1
  }
  Quit tStatus
}

(Edited for formatting.)

I prefer doing this more correctly using the right API for matching status values:

If $system.Status.Equals(sc,$$$ERRORCODE($$$GeneralError),$$$ERRORCODE($$$MoreSpecificStatusCode),...) {
  // Handle specific error(s)
}

The use of ' can result in unexpected behaviour when you are checking for a 4 digit code, but are handling a 3 digit code...

Note that it's also safer to wrap status codes in $$$ERRORCODE($$$TheErrorCode), but that may not be necessary depending on the specific context.