Let's look at a couple of simple scenarios:

Loading and Editing Data

oDev = CREATEOBJECT("wwDevRegistry")
IF !oDev.Load(1)   && Load PK 1
   ? loDev.cErrorMsg
   RETURN
ENDIF

? loDev.oData.Company
? loDev.oData.Contact
? loDev.PK   && 1

*** New oData member - note not written yet
loDev.New()

loDev.Company = "West Wind"
loDev.Contact = "Rick Strahl"
loDev.oData.Address = "301 N. 15th Street"
loDev.oData.City = "Hood River"
loDev.oData.State = "OR"
loDev.oData.Zip = "97031"

lnPK =  loDev.PK   && 144

*** Validate() must be implemented
IF !loDev.Validate()
   ? loDev.cErrorMsg
   RETURN 
ENDIF

*** Now write the data to disk
IF !loDev.Save()
   ? loDev.cErrorMsg
   RETURN 
ENDIF

*** Clear data
loDev.GetBlankRecord()

loDev.Load(lnPK)  && 144

? loDev.oData.Company  && West Wind
<&lt;/PRE&gt;>

Querying data

<&lt;PRE&gt;>oDev = CREATEOBJECT("wwDevRegistry")

? oDev.Query()      && Return all records
BROWSE

*** Full query
? oDev.Query("SELECT * FROM wwDevRegistry where submitted > " + TIMETOCSTRICT(DATE()-10) )
BROWSE

You can also run multitable queries through the query method - the SQL is basically passed straight through to the back end plus a few checks. For Fox data this means a macro eval for SQL statement, or a SQLExecute command (SQL Passthrough) run through the wwSQL object.

Query performs a few checks and sets up requests by looking for missing pieces in a SQL string. For example with Query you don't specify an INTO clause. If you want a more direct method to access data you can use the Execute method which requires a fully qualified command. These will differ for Fox and SQL data so you should minimize using Execute if you're worried about running both Fox and SQL data. Execute is more efficient so if you are bracketing your code anyway, then Execute is a good choice. Typically you'll use Execute if you need to hit SQL Server where the same Fox code runs as 'native' Fox code. For example the Find method in wwBusiness uses a native VFP command (LOCATE) while the SQL code uses Execute to run a SQL statement:

DO CASE
   CASE THIS.nDataMode = 0
      lcCmd = "LOCATE FOR " + lcFilter
      &lcCmd

      IF FOUND()
         SCATTER NAME THIS.oData MEMO
         RETURN .T.
      ENDIF
   CASE THIS.nDataMode = 2
      THIS.oSQL.cSQLCursor = "TSQLQuery"
      THIS.oSQL.cSQL = "select * from " + THIS.cAlias + " WHERE " + lcFilter
      *_cliptext = THIS.oSQL.cSQL
      lnResult = THIS.oSQL.Execute()

      IF lnResult # 1
         THIS.seterror(THIS.oSQL.cErrorMsg)
         RETURN .F.
      ENDIF
      IF RECCOUNT() > 0
         SCATTER NAME THIS.oData MEMO
         RETURN
      ENDIF
ENDCASE

You should minimize using explicit query commands in your client code however and create specialized methods in the business object to return data. For example, in the devregistry class i may have a method called GetEntriesByDate that I just pass a date to. The method would then create the appropriate SQL command to call with the Query method. In its simplest form this would be something like this:

FUNCTION GetEntriesByDate(ldDate as DateTime) as Integer
RETURN THIS.Query( oDev.Query("SELECT * FROM wwDevRegistry where submitted > " + TIMETOCSTRICT(ldDate) )
ENDFUNC

Returning different types of data
You can also return data in different formats by using the nResultMode property which allows you to return data in XML format for example.

oDev.nResultMode = 2  && XML Cursor
oDev.Query()

lcXML = oDev.cResultXML

or to create XML from the current oData member:

oDev.ConvertData(4)
lcXML = oDev.cResultXML