I’d recently been plugged into a new project and asked to determine what specific tables or views were needed to move into a new environment. Apart from being unfamiliar with all of the data layer clockwork, I also didn’t have access to the RDBMS.

My first stop was to the SmartForm, to identify the SmartObjects involved. I could find the calls within the rules.

My next stop is the SmartObjects Service Tester. I found each of the SmO’s and right-clicked to view their XML. To get the code out of the form window, I selected all and copied it into a blank text file, then started going through the XML to find the objects they were predicated on.

The XML gave me the names of table or view objects the SmO was built upon. If the SmO was derived from a stored procedure in a package, the XML gave me the name of the package and the name of the procedure, which I could then pass along in a request to the DBA’s.

The format of a SmartObject based on a database object resembles this:


<smartobjectroot>
  <metadata>
  <types>
  <properties>
  <methods> *
  <serviceinstances>
  <objects>


* if you have a SmartObject with a single method, the tag will read <method>

The information under the <serviceinstances> node will name the service instance and identify the GUID and type (e.g., type=”SourceCode.SmartObjects.Services.SQL.SqlServerService”).

The information under the <objects> node will identify the objects the SmartObject is based on (e.g., “<object name=’usp_getShoeColors’ type=’StoredProc’ active=’true’ version=”>”).

So in that text file you dumped all that XML into, do a search on “<serviceinstances>” or “<objects>” to get to the information you need fast.