[ Pobierz całość w formacie PDF ]
.10-26 Dev el oper s Gui de Cr o s s - p l a t f o r m d a t a b a s e a p p l i c a t i o n s" If the original dataset was a TStoredProc, TADOStoredProc, or TIBStoredProccomponent, set the new TSQLStoredProc component s StoredProcName to theStoredProcName or ProcedureName property of the original dataset.Set theParams property of the new TSQLStoredProc to match the value of the originaldataset s Params or Parameters property.6 For any database connection components in the original application (TDatabase,TIBDatabase, or TADOConnection), add a TSQLConnection component to the newdata module.You must also add a TSQLConnection component for every databaseserver to which you connected without a connection component (for example, byusing the ConnectionString property on an ADO dataset or by setting theDatabaseName property of a BDE dataset to a BDE alias).7 For each dbExpress dataset placed in step 4, set its SQLConnection property to theTSQLConnection component that corresponds to the appropriate databaseconnection.8 On each TSQLConnection component, specify the information needed to establish adatabase connection.To do so, double-click the TSQLConnection component todisplay the Connection Editor and set parameter values to indicate theappropriate settings.If you had to transfer data to a new database server in step 1,then specify settings appropriate to the new server.If you are using the sameserver as before, you can look up some of this information on the originalconnection component:" If the original application used TDatabase, you must transfer the informationthat appears in the Params and TransIsolation properties." If the original application used TADOConnection, you must transfer theinformation that appears in the ConnectionString and IsolationLevel properties." If the original application used TIBDatabase, you must transfer the informationthat appears in the DatabaseName and Params properties." If there was no original connection component, you must transfer theinformation associated with the BDE alias or that appeared in the dataset sConnectionString property.You may want to save this set of parameters under a new connection name.Formore details on this process, see Controlling connections on page 17-2.Updating data in dbExpress applicationsdbExpress applications use client datasets to support editing.When you post edits to aclient dataset, the changes are written to the client dataset s in-memory snapshot ofthe data, but are not automatically written to the database server.If your originalapplication used a client dataset for caching updates, then you do not need to changeanything to support editing on Linux.However, if you relied on the default behaviorof most datasets on Windows, which is to write edits to the database server whenyou post records, you must make changes to accommodate the use of a client dataset.Us i ng CLX f or cr os s - pl at f or m dev el opment 10-27 Cr o s s - p l a t f o r m d a t a b a s e a p p l i c a t i o n sThere are two ways to convert an application that did not previously cache updates:" You can mimic the behavior of the dataset on Windows by writing code to applyeach updated record to the database server as soon as it is posted.To do this,supply the client dataset with an AfterPost event handler that applies update to thedatabase server:procedure TForm1.ClientDataSet1AfterPost(DataSet: TDataSet);beginwith DataSet as TClientDataSet doApplyUpdates(1);end;" You can adjust your user interface to deal with cached updates.This approach hascertain advantages, such as reducing the amount of network traffic andminimizing transaction times.However, if you switch to using cached updates,you must decide when to apply those updates back to the database server, andprobably make user interface changes to let users initiate the application ofupdates or inform provide them with feedback about whether their edits havebeen written to the database.Further, because update errors are not detected whenthe user posts a record, you will need to change the way you report such errors tothe user, so that they can see which update caused a problem as well as what typeof problem occurred.If your original application used the support provided by the BDE or ADO forcaching updates, you will need to make some adjustments in your code to switch tousing a client dataset.The following table lists the properties, events, and methodsthat support cached updates on BDE and ADO datasets, and the correspondingproperties, methods and events on TClientDataSet:Table 10.11 Properties, methods, and events for cached updatesOn BDE datasets(or TDatabase) On ADO datasets On TClientDataSet PurposeCachedUpdates LockType Not needed, client Determines whether cacheddatasets always updates are in effect.cache updates.Not supported.CursorType Not supported.Specifies how isolated the datasetis from changes on the server.UpdatesPending Not supported.ChangeCount Indicates whether the local cachecontains updated records thatneed to be applied to thedatabase.UpdateRecordTypes FilterGroup StatusFilter Indicates the kind of updatedrecords to make visible whenapplying cached updates.UpdateStatus RecordStatus UpdateStatus Indicates if a record is unchanged,modified, inserted, or deleted.OnUpdateError Not supported.OnReconcileError An event for handling updateerrors on a record-by-record basis.ApplyUpdates UpdateBatch ApplyUpdates Applies records in the local cache(on dataset or to the database.database)10-28 Dev el oper s Gui de Cr o s s - p l a t f o r m I n t e r n e t a p p l i c a t i o n sTable 10 [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.10-26 Dev el oper s Gui de Cr o s s - p l a t f o r m d a t a b a s e a p p l i c a t i o n s" If the original dataset was a TStoredProc, TADOStoredProc, or TIBStoredProccomponent, set the new TSQLStoredProc component s StoredProcName to theStoredProcName or ProcedureName property of the original dataset.Set theParams property of the new TSQLStoredProc to match the value of the originaldataset s Params or Parameters property.6 For any database connection components in the original application (TDatabase,TIBDatabase, or TADOConnection), add a TSQLConnection component to the newdata module.You must also add a TSQLConnection component for every databaseserver to which you connected without a connection component (for example, byusing the ConnectionString property on an ADO dataset or by setting theDatabaseName property of a BDE dataset to a BDE alias).7 For each dbExpress dataset placed in step 4, set its SQLConnection property to theTSQLConnection component that corresponds to the appropriate databaseconnection.8 On each TSQLConnection component, specify the information needed to establish adatabase connection.To do so, double-click the TSQLConnection component todisplay the Connection Editor and set parameter values to indicate theappropriate settings.If you had to transfer data to a new database server in step 1,then specify settings appropriate to the new server.If you are using the sameserver as before, you can look up some of this information on the originalconnection component:" If the original application used TDatabase, you must transfer the informationthat appears in the Params and TransIsolation properties." If the original application used TADOConnection, you must transfer theinformation that appears in the ConnectionString and IsolationLevel properties." If the original application used TIBDatabase, you must transfer the informationthat appears in the DatabaseName and Params properties." If there was no original connection component, you must transfer theinformation associated with the BDE alias or that appeared in the dataset sConnectionString property.You may want to save this set of parameters under a new connection name.Formore details on this process, see Controlling connections on page 17-2.Updating data in dbExpress applicationsdbExpress applications use client datasets to support editing.When you post edits to aclient dataset, the changes are written to the client dataset s in-memory snapshot ofthe data, but are not automatically written to the database server.If your originalapplication used a client dataset for caching updates, then you do not need to changeanything to support editing on Linux.However, if you relied on the default behaviorof most datasets on Windows, which is to write edits to the database server whenyou post records, you must make changes to accommodate the use of a client dataset.Us i ng CLX f or cr os s - pl at f or m dev el opment 10-27 Cr o s s - p l a t f o r m d a t a b a s e a p p l i c a t i o n sThere are two ways to convert an application that did not previously cache updates:" You can mimic the behavior of the dataset on Windows by writing code to applyeach updated record to the database server as soon as it is posted.To do this,supply the client dataset with an AfterPost event handler that applies update to thedatabase server:procedure TForm1.ClientDataSet1AfterPost(DataSet: TDataSet);beginwith DataSet as TClientDataSet doApplyUpdates(1);end;" You can adjust your user interface to deal with cached updates.This approach hascertain advantages, such as reducing the amount of network traffic andminimizing transaction times.However, if you switch to using cached updates,you must decide when to apply those updates back to the database server, andprobably make user interface changes to let users initiate the application ofupdates or inform provide them with feedback about whether their edits havebeen written to the database.Further, because update errors are not detected whenthe user posts a record, you will need to change the way you report such errors tothe user, so that they can see which update caused a problem as well as what typeof problem occurred.If your original application used the support provided by the BDE or ADO forcaching updates, you will need to make some adjustments in your code to switch tousing a client dataset.The following table lists the properties, events, and methodsthat support cached updates on BDE and ADO datasets, and the correspondingproperties, methods and events on TClientDataSet:Table 10.11 Properties, methods, and events for cached updatesOn BDE datasets(or TDatabase) On ADO datasets On TClientDataSet PurposeCachedUpdates LockType Not needed, client Determines whether cacheddatasets always updates are in effect.cache updates.Not supported.CursorType Not supported.Specifies how isolated the datasetis from changes on the server.UpdatesPending Not supported.ChangeCount Indicates whether the local cachecontains updated records thatneed to be applied to thedatabase.UpdateRecordTypes FilterGroup StatusFilter Indicates the kind of updatedrecords to make visible whenapplying cached updates.UpdateStatus RecordStatus UpdateStatus Indicates if a record is unchanged,modified, inserted, or deleted.OnUpdateError Not supported.OnReconcileError An event for handling updateerrors on a record-by-record basis.ApplyUpdates UpdateBatch ApplyUpdates Applies records in the local cache(on dataset or to the database.database)10-28 Dev el oper s Gui de Cr o s s - p l a t f o r m I n t e r n e t a p p l i c a t i o n sTable 10 [ Pobierz całość w formacie PDF ]