Once you've created a business object using the class is really straight forward. By default the Wizard sets all properties you need to start up and running. You can of course override any of the settings the Wizard made at runtime.
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.oData.Company = "West Wind" loDev.oData.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
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
Comment or report problem with topic