[ Pobierz całość w formacie PDF ]
.Providers work in conjunction with resolvercomponents that handle the details of resolving data to the database or dataset.Most of the work of a provider component happens automatically.You need notwrite any code on the provider to create a fully functioning application server.However, provider components include a number of events and properties thatallow your application more direct control over what information is packaged forclients and how your application responds to client requests.This chapter describes how to use a provider component to control the interactionwith client applications.Determining the source of dataWhen you use a provider component, you must specify a dataset that it can use to getthe data it assembles into data packets.To do this, set the DataSet property of theprovider to the name of the dataset to use.At design time, select from availabledatasets in the DataSet property drop-down list in the Object Inspector.TDataSetProvider can work with any dataset that supports the IProviderSupportinterface.This interface is introduced by TDataSet, so it is available for all datasets.However, the IProviderSupport methods implemented in TDataSet are mostly stubsthat don t do anything or that throw exceptions.Most of the dataset classes that shipwith C++Builder (BDE-enabled datasets, ADO-enabled datasets, Client datasets, andInterBase Express components) override these methods to implement theIProviderSupport interface in a more useful fashion.Us i ng pr ov i der c omponent s 16-1 Ch o o s i n g h o w t o a p p l y u p d a t e sNote Because the provider relies on an interface belonging to the dataset, it has no specificdependencies on the data access mechanism (BDE, DBOLE, or some othermechanism).These dependencies all fall to the dataset that the provider uses.Component writers that create their own custom descendants from TDataSet mustoverride all appropriate IProviderSupport methods if their datasets are to work in anapplication server.If the provider only provides data packets on a read-only basis(that is, if it does not apply updates), the IProviderSupport methods implemented inTDataSet may be sufficient.Choosing how to apply updatesBy default, when TDataSetProvider components apply updates and resolve updateerrors, they communicate directly with the database server using dynamicallygenerated SQL statements.This approach has the advantage that your serverapplication does not need to merge updates twice (first to the dataset, and then to theremote server).However, you may not always want to take this approach.For example, you maywant to use some of the events on the dataset component.Alternately, the datasetyou use may not support the use of SQL statements (for example if you are providingfrom a TClientDataSet component).TDataSetProvider lets you decide whether to apply updates to the database serverusing SQL or to the source dataset by setting the ResolveToDataSet property.Whenthis property is true, updates are applied to the dataset.When it is false, updates areapplied directly to the underlying database server.Controlling what information is included in data packetsThere are a number of ways to control what information is included in data packetsthat are sent to and from the client.These include" Specifying what fields appear in data packets" Setting options that influence the data packets" Adding custom information to data packetsSpecifying what fields appear in data packetsTo control what fields are included in data packets, create persistent fields on thedataset that the provider uses to build the packets.The provider then includes onlythese fields.Fields whose values are generated dynamically on the server (such ascalculated fields or lookup fields) can be included, but appear to client datasets onthe receiving end as static read-only fields.For information about creating persistentfields, see  Creating persistent fields on page 20-5.16-2 Dev el oper  s Gui de Co n t r o l l i n g wh a t i n f o r ma t i o n i s i n c l u d e d i n d a t a p a c k e t sIf the client dataset will be editing the data and applying updates to the applicationserver, you must include enough fields so that there are no duplicate records in thedata packet.Otherwise, when the updates are applied, it is impossible to determinewhich record to update.If you do not want the client dataset to be able to see or useextra fields provided only to ensure uniqueness, set the ProviderFlags property forthose fields to include pfHidden.Note Including enough fields to avoid duplicate records is also a consideration whenusing queries on the application server.The query should include enough fields sothat records are unique, even if your application does not use all the fields.Setting options that influence the data packetsThe Options property of the provider component lets you specify when BLOBs ornested detail tables are sent, whether field display properties are included, what typeof updates are allowed, and so on.The following table lists the possible values thatcan be included in Options.Table 16.1 Provider optionsValue MeaningpoFetchBlobsOnDemand BLOB field values are not included in the data packet.Instead,client applications must request these values on an as-neededbasis.If the client dataset s FetchOnDemand property is true, theclient requests these values automatically.Otherwise, the clientapplication uses the client dataset s FetchBlobs method to retrieveBLOB data.poFetchDetailsOnDemand When the provider represents the master of a master/detailrelationship, nested detail values are not included in the datapacket.Instead, client applications request these on an as-neededbasis.If the client dataset s FetchOnDemand property is true, theclient requests these values automatically.Otherwise, the clientapplication uses the client dataset s FetchDetails method toretrieve nested details.poIncFieldProps The data packet includes the following field properties (whereapplicable): Alignment, DisplayLabel, DisplayWidth, Visible,DisplayFormat, EditFormat, MaxValue, MinValue, Currency,EditMask, DisplayValues.poCascadeDeletes When the provider represents the master of a master/detailrelationship, detail records are deleted by the serverautomatically when master records are deleted.To use thisoption, the database server must be set up to perform cascadeddeletes as part of its referential integrity.poCascadeUpdates When the provider represents the master of a master/detailrelationship, key values on detail tables are updatedautomatically when the corresponding values are changed inmaster records.To use this option, the database server must beset up to perform cascaded updates as part of its referentialintegrity.poReadOnly The client dataset can t apply updates to the provider.Us i ng pr ov i der c omponent s 16-3 Co n t r o l l i n g wh a t i n f o r ma t i o n i s i n c l u d e d i n d a t a p a c k e t sTable 16.1 Provider options (continued)Value MeaningpoAllowMultiRecordUpdates A single update can cause more than one record of theunderlying database table to change.This can be the result oftriggers, referential integrity, custom SQL statements, and so on [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • funlifepok.htw.pl

    •