Tuesday, May 26, 2009

Tentative definitions

The ANSI C standard supports the concept of the tentative definition. Any external data declaration that has no storage class specifier and no initializer is considered a tentative definition. If the identifier declared appears in a later definition, then the tentative definition is treated as if the extern storage class specifier were present. In other words, the tentative definition becomes a simple referencing declaration.

If the end of the translation unit is reached and no definition has appeared with an initializer for the identifier, then the tentative definition becomes a full definition, and the object defined has uninitialized (zero-filled) space reserved for it. For example,

int x;

int x; /*legal, one copy of x is reserved */
int y;
int y = 4; /* legal, y is initialized to 4 */
int z = 5;

int z = 6; /* not legal, both are initialized definitions */

Unlike ANSI C, C++ doesn't have the concept of a tentative declaration; an external data declaration without a storage class specifier is always a definition.

TClientDataSet

TClientDataSet implements a database-independent dataset.

Unit

dbclient

Description

TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a

Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
Client dataset in the client application portion of a multi-tiered database application.

Note: The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.

The client dataset can communicate with a data provider directly by calling the provider component’
s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.

IAppServer::AS_Execute

Executes the query or stored procedure bound to a specified provider. virtual HRESULT __safecall AS_Execute(const WideString: ProviderName, const WideString: CommandText, OleVariant &Params, OleVariant &OwnerData) = 0 ; Description Use AS_Execute to pass an execute command to a remote provider, using a specified set of parameters. AS_Execute calls the Execute method of the specified provider after assigning any parameters. Output parameters that result from executing a query or stored procedure are returned in the Params parameter. Note: Different types of provider interpret the Execute command in different ways. Some providers merely generate BeforeExecute and AfterExecute events, while others execute a query or stored procedure. The ProviderName parameter specifies the name of the provider component associated with the query or stored procedure. CommandText specifies an optional SQL statement that replaces the SQL of the provider’s query, or the name of a stored procedure that replaces the provider’s stored procedure. This parameter is ignored if the Options property does not include poAllowCommandText. Web Hosting The Params parameter encodes any parameters expected by the query or stored procedure and returns any output parameters. To create a properly encoded value for Params from a TParams object, use the PackageParams routine. To decode Params into a TParams object, use the UnpackParams routine. The OwnerData parameter contains custom information that appears as an argument to the provider’s BeforeExecute and AfterExecute event handlers. This information originates in a client dataset’s BeforeExecute event handler. The value returned in OwnerData is passed to the client dataset’s AfterExecute event handler. Client applications must explicitly call AS_Execute through the client dataset’s Execute method. C++Builder does not call AS_Execute automatically.

Field Link designer

The Field Link Designer provides a visual way to link (join) master and detail tables.
At design time, drop a TDataSource object on the form and define a datasource. Select the TTable component and double-click the MasterFields property in the Object Inspector to invoke the Field Link designer.

Available Indexes combo box


The Available Indexes combo box shows the currently selected index used to join the tables. Unless you specify a different index name in the table’s IndexName property, the default index used for the link is the primary index for the table. Other available indexes defined on the table can be selected from the drop-down list.

To link master and detail tables:

1 Select the field to use to link the detail table in the Detail Fields list
2 Select the field to link the master table in the Master Fields list.
3 Choose Add.

The selected fields are be displayed in the Joined Fields list box. For example,

OrderNo -> OrderNo

Note:
For tables on a database server, the Available Indexes combo box will not appear, and you must manually select the detail and master fields to join in the Detail Fields and Master Fields list boxes.

BeforeGetRecords, Active, CloneCursor, FetchOnDemand Example

This example shows how to use the BeforeGetRecords event handler to send the application server information it needs for incremental data fetching. Before fetching the next data packet, the client dataset packages up the key value of the last record so that the application server knows where to begin the next data packet. It also sends some application-specific information, which is stored in Memo1.

void __fastcall TForm1::ClientDataSet1BeforeGetRecords(TObject *Sender, OleVariant &OwnerData)
{
OleVariant[2] Values;
Values[0] = NULL;
if (ClientDataSet1->Active)
{
ClientDataSet *CDSClone = new ClientDataSet(Form1);
try
{
CDSClone->CloneCursor(ClientDataSet1, true);
// turn off FetchOnDemand so that the clone only
// fetches the last LOCAL record
CDSClone->FetchOnDemand = false;
CDSClone->Last();
Values[0] = CDSClone->Fields->Fields[0]->Value;
CDSClone->Close();
}
__finally
{
delete CDSClone;
}
}
Values[1] = Memo1->Lines->Text;
OwnerData = VarArrayOf(Values,1);
}

Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris
GPS location


TClientDataSet::FetchOnDemand

Indicates whether to fetch data packets from the provider on an as needed basis.

__property bool FetchOnDemand = {read=FFetchOnDemand, write
=FFetchOnDemand, default=1};

Description


By default FetchOnDemand is true, meaning that the client dataset fetches additional packets of data as needed (for example, as a user scrolls through data, or conducts a search). If the server does not automatically include BLOB fields or nested detail sets in data packets, setting FetchOnDemand to true causes the client dataset to fetch these values when needed as well.

Set FetchOnDemand to false only if your client application contains code that explicitly fetches data packets as needed using the GetNextPacket method. Similarly, if FetchOnDemand is false, and the provider component does not include BLOB data by default (Options includes poFetchBlobsOnDemand), the client application must fetch BLOB fields explicitly using the FetchBlobs method. If the provider does not include nested detail sets (Options includes poFetchDetailsOnDemand) and FetchOnDemand is false, the client application must fetch nested details explicitly using the FetchDetails method.

FetchOnDemand Example

Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris

TClientDataSet::GetNextPacket

Retrieves the next block of records from the application server.

int __fastcall
GetNextPacket(void);

Description

Call GetNextPacket to retrieve the next sequential block of records from the application server. To specify the maximum number of records to return in a packet, set the PacketRecords property before calling GetNextPacket. A packet is appended to those records already stored in the Data property.

GetNextPacket returns the number of records added to Data. If the return value is 0, the client application has already received all available records from the application server.

Warning: If the client dataset uses a stateless application server, you must use a BeforeGetRecords event handler to ensure that the data packet returns the correct set of records.

Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris

TClientDataSet::FetchDetails

Retrieves nested detail datasets from the application server.

void __fastcall FetchDetails(void);

Description


Call FetchDetails to retrieve nested detail sets from an application server when this information is not provided automatically. Nested details are automatically included in data packets unless the provider on the application server includes poFetchDetailsOnDemand in its Options property. FetchDetails updates the current record to include the missing detail data sets.

There is no need to call FetchDetails if the provider automatically includes nested detail sets or if the client dataset’s FetchOnDemand property is true.

TBaseProvider::Options

Influences what is included in data packets and how the information in data packets is used.

__property
TProviderOptions Options = {read=FProviderOptions, write
=FProviderOptions, default=0};

Description

Set Options to customize how the provider communicates with client datasets. Options is a set that specifies

Whether nested detail sets and BLOB data are included in data packets or fetched separately.
Whether data packets include field component properties such as formats, display names, and maximum & minimum values.
Whether data packets are provided on a read-only basis, and whether specific types of changes (insertions, edits, or deletions) are disabled.
Whether changes to master table fields should cause corresponding updates to detail tables.

Whether a single client update can affect multiple server records.
Whether the clients records are refreshed when it applies updates.
Whether the client can send SQL statements that override the provider’s dataset.

Note: Not all options are supported by an InternetExpress client. Specifically, InternetExpress clients don’t support poFetchBlobsOnDemand, poFetchDetailsOnDemand, poDisableInserts, poDisableEdits, psDisableDeletes, poPropogateChanges, and poAllowCommandText.



Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris

TClientDataSet::FetchBlobs

Retrieves BLOB field values from the application server.

void __fastcall FetchBlobs(void);

Description

Call FetchBlobs to retrieve BLOB field values from an application server when this information is not provided automatically. BLOB field values are automatically included in data packets unless the provider on the application server includes poFetchBlobsOnDemand in its Options property.

There is no need to call FetchBlobs if the provider automatically includes BLOB data or if the client dataset’s FetchOnDemand property is true.

cdecl, _cdecl, __cdecl

Category

Modifiers, C++Builder keyword extensions

Syntax

cdecl ;

_cdecl
;

__cdecl ;

Description


Use a cdecl, _cdecl, or __cdecl modifier to declare a variable or a function using the C-style naming conventions (case-sensitive, with a leading underscore appended). When you use cdecl, _cdecl, or __cdecl in front of a function, it affects how the parameters are passed (parameters are pushed right to left, and the caller cleans up the stack). The __cdecl modifier overrides the compiler directives and IDE options.

The cdecl, _cdecl, and __cdecl keywords are specific to C++Builder.

Linkage

An executable program is usually created by compiling several independent translation units, then linking the resulting object files with preexisting libraries. A problem arises when the same identifier is declared in different scopes (for example, in different files), or declared more than once in the same scope. Linkage is the process that allows each instance of an identifier to be associated correctly with one particular object or function. All identifiers have one of three linkage attributes, closely related to their scope: external linkage, internal linkage, or no linkage. These attributes are determined by the placement and format of your declarations, together with the explicit (or implicit by default) use of the storage class specifier static or extern.

Each instance of a particular identifier with external linkage represents the same object or function throughout the entire set of files and libraries making up the program. Each instance of a particular identifier with internal linkage represents the same object or function within one file only. Identifiers with no linkage represent unique entities.

External and internal linkage rules

Any object or file identifier having file scope will have internal linkage if its declaration contains the storage class specifier static.
For C++, if the same identifier appears with both internal and external linkage within the same file, the identifier will have external linkage. In C, it will have internal linkage.
If the declaration of an object or function identifier contains the storage class specifier extern
, the identifier has the same linkage as any visible declaration of the identifier with file scope. If there is no such visible declaration, the identifier has external linkage.

If a function is declared without a storage class specifier, its linkage is determined as if the storage class specifier extern had been used.
If an object identifier with file scope is declared without a storage class specifier, the identifier has external linkage.

Identifiers with no linkage attribute:

Any identifier declared to be other than an object or a function (for example, a typedef identifier)
Function parameters
Block scope identifiers for objects declared without the storage class specifier extern

Name mangling

When a C++ module is compiled, the compiler generates function names that include an encoding of the function's argument types. This is known as name mangling. It makes overloaded functions possible, and helps the linker catch errors in calls to functions in other modules. However, there are times when you won't want name mangling. When compiling a C++ module to be linked with a module that does not have mangled names, the C++ compiler has to be told not to mangle the names of the functions from the other module. This situation typically arises when linking with libraries or .OBJ files compiled with a C compiler

To tell the C++ compiler not to mangle the name of a function, declare the function as extern "C", like this:

extern "C" void Cfunc( int );

This declaration tells the compiler that references to the function Cfunc should not be mangled.

You can also apply the extern "C" declaration to a block of names:

extern "C" {

void Cfunc1( int );
void Cfunc2( int );
void Cfunc3( int );

};

As with the declaration for a single function, this declaration tells the compiler that references to the functions Cfunc1, Cfunc2, and Cfunc3 should not be mangled. You can also use this form of block declaration when the block of function names is contained in a header file:

extern "C" {

#include "locallib.h"

};


Note: extern “C” cannot be used with class identifiers.



Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris

OleVariant

OleVariant is a C++Builder implementation of the Object Pascal intrinsic type OleVariant.

Header

sysvari.h

Description

OleVariant is a special descendant of the Variant class that is used to represent COM interfaces or data that is passed over a COM interface. OleVariant inherits from Variant as a protected class so that it can prevent operations on AnsiString objects, which are not compatible with COM.

The syntax for using OleVariant is the same as that for using the Variant class. Like the Variant class, OleVariant has the following characteristics:

OleVariants can contain integer values, real values, string values, boolean values, date-and-time values, and Automation objects. In addition, OleVariants can contain arrays of varying size and dimension with elements of any of these types.
The special OleVariant value Unassigned is used to indicate that a OleVariant has not yet been assigned a value, and the special OleVariant value Null is used to indicate unknown or missing data.
A OleVariant can be combined with other OleVariants and it can be constructed from any of the following data types. The compiler automatically performs the necessary type conversions.

• short WordBool
• int Byte
• float Variant
• double WideString
• Currency wchar_t*
• TDateTime Ole2::IDispatch*
• bool Ole2::IUnknown*



When an OleVariant contains an Automation object, the OleVariant can be used to get and set properties of the object, and to invoke methods on the object.

OleVariant variables are always initialized to be Unassigned when they are first created. This is true whether a OleVariant variable is global, local, or part of a structure such as an array.

Note that while OleVariants offer great flexibility, they also consume more memory than regular variables, and operations on OleVariants are substantially slower than operations on statically typed values.

Note: Use only the operators declared within OleVariant. The compiler will ignore any operators you overload yourself.
Note: For binary operators, if one operand is of type OleVariant, the other operand is automatically converted to type OleVariant.

TClientDataSet::AppendData

Adds a newly fetched packet of records to those already stored in the client dataset.

void __fastcall AppendData(const System::OleVariant &Data, bool HitEOF);

Description

Use AppendData to add a newly fetched packet of records from the server application to the client dataset. Data indicates the packet of records to add. HitEOF indicates whether or not the application server encountered the end of the dataset when it fetched the records from the database server.

Most applications call GetNextPacket instead to fetch a packet of records and automatically add them to those already available. Use AppendData when fetching data packets directly from the application server rather than letting the client dataset fetch data.

Wednesday, May 13, 2009

MIDAS technology

1.Understanding MIDAS technology
MIDAS requires MIDAS.DLL, which is used by both client and server applications to manage datasets stored as data packets. Building MIDAS applications may also require the SQL explorer to help in database administration and to import server constraints into the Data Dictionary so that they can be checked at any level of the multi-tiered application.
NB:You must purchase server licenses for deploying your MIDAS applications.

Component and there Description
remote data modules-Specialized data modules that work with a COM Automation server to give client applications access to any providers they contain. Used on the application server.

provider component -A data broker that provides data by creating data packets and resolves client updates. Used on the application server.

client dataset component-A specialized dataset that uses MIDAS.DLL to manage data stored in data packets.
connection components-A family of components that locate the server, form connections, and make the IAppServer interface available to client datasets. Each connection component is specialized to use a particular communications protocol.

2.Building a multi-tiered application
The general steps for creating a multi-tiered database application are

i)Create the application server.

ii)Register or install the application server.
If the application server uses DCOM, HTTP, or sockets as a communication protocol, it acts as an Automation server and must be registered like any other r COM server. For information about registering an application, see Registering a COM object.
If you are using a transactional data module, you do not register the application server. Instead, you install it with MTS or COM+. For information about installing transactional objects, see Installing transactional objects.

iii)Create a client application.
The order of creation is important. You should create and run the application server before you create a client. At design time, you can then connect to the application server to test your client. You can, of course, create a client without specifying the application server at design time, and only supply the server name at runtime. However, doing so prevents you from seeing if your application works as expected when you code at design time, and you will not be able to choose servers and providers using the Object Inspector.


NB If you are not creating the client application on the same system as the server, and you are not using a Web connection or socket connection, you may want to register or install the application server on the client system. This makes the connection component aware of the application server at design time so that you can choose server names and provider names from a drop-down list in the Object Inspector. (If you are using a Web connection or socket connection, the connection component fetches the names of registered servers from the server machine.)

Advantages of the multi-tiered database model

The multi-tiered database model breaks a database application into logical pieces. The client application can focus on data display and user interactions. Ideally, it knows nothing about how the data is stored or maintained. The application server (middle tier) coordinates and processes requests and updates from multiple clients. It handles all the details of defining datasets and interacting with the remote database server.
The advantages of this multi-tiered model include the following:

Encapsulation of business logic in a shared middle tier. Different client applications all access the same middle tier. This allows you to avoid the redundancy (and maintenance cost) of duplicating your business rules for each separate client application.

Thin client applications. Your client applications can be written to make a small footprint by delegating more of the processing to middle tiers. Not only are client applications smaller, but they are easier to deploy because they don’t need to worry about installing, configuring, and maintaining the database connectivity software (such as the Borland Database Engine). Thin client applications can be distributed over the Internet for additional flexibility.


Distributed data processing.
Distributing the work of an application over several machines can improve performance because of load balancing, and allow redundant systems to take over when a server goes down.

Increased opportunity for security. You can isolate sensitive functionality into tiers that have different access restrictions. This provides flexible and configurable levels of security. Middle tiers can limit the entry points to sensitive material, allowing you to control access more easily. If you are using HTTP or MTS, you can take advantage of the security models they support.

MIDAS Program

Distributing database applications
C++Builder provides support for creating distributed database applications using the MIDAS technology. This powerful technology includes a coordinated set of components that allow you to build a wide variety of multi-tiered database applications. Distributed database applications can be built on a variety of communications protocols, including DCOM, TCP/IP, and OLEnterprise


Creating multi-tiered applications.
A multi-tiered client/server application is partitioned into logical units which run in conjunction on separate machines. Multi-tiered applications share data and communicate with one another over a local-area network or even over the Internet. They provide many benefits, such as centralized business logic and thin client applications.

In its simplest form, sometimes called the “three-tiered model,” a multi-tiered application is partitioned into thirds:
-Client application: provides a user interface on the user’s machine.
-Application server: resides in a central networking location accessible to all clients and provides common data services.
-Remote database server: provides the relational database management system (RDBMS).

In this three-tiered model, the application server manages the flow of data between clients and the remote database server, so it is sometimes called a “data broker.” With C++Builder you usually only create the application server and its clients, although, if you are really ambitious, you could create your own database back end as well.
In more complex multi-tiered applications, additional services reside between a client and a remote database server. For example, there might be a security services broker to handle secure Internet transactions, or bridge services to handle sharing of data with databases on platforms not directly supported by C++Builder.
C++Builder support for multi-tiered applications is based on the Multi-tier Distributed Application Services Suite (MIDAS)

__msreturn

__msreturn
Category

Modifiers, C++Builder keyword extensions

Syntax
__msreturn

Description
This calling convention is used for Microsoft compatible __fastcall calling convention return values. Structures with a size that is greater than 4 bytes and less than 9 bytes, and having at least one of its members sized 4 bytes or larger, are returned in EAX/EDX.
Calling convention mangling compatibility option
(Command-line switch: -VC)
When this option is set, the compiler disables the distinction of function names where the only possible difference is incompatible code generation options. For example, with this option set, the linker will not detect if a call is made to a _ _fastcall member function with the cdecl calling convention.
This option is provided for backward compatibility only; it lets you link old library files that you cannot recompile.

Default = OFF

__msfastcall

__msfastcall
Category
Modifiers, C++Builder keyword extensions

Syntax

__msfastcall

Description
This calling convention emulates the Microsoft implementation of the fastcall calling convertion. The first two DWORD or smaller arguments are passed in ECX and EDX registers, all other arguments are passed from right to left. The called function is responsible for removing these arguments from the stack.

_export, __export

Category

Modifiers, C++Builder keyword extensions

Form 1
class _export

Form 2

return_type _export

Form 3

data_type _export

Description
These modifiers are used to export classes, functions, and data.
The linker enters functions flagged with _export or __export into an export table for the module.
Using _export or __export eliminates the need for an EXPORTS section in your module definition file.
Functions that are not modified with _export or __export receive abbreviated prolog and epilog code, resulting in a smaller object file and slightly faster execution.

NB:
If you use _export or __export to export a function, that function will be exported by name rather than by ordinal (ordinal is usually more efficient).
If you want to change various attributes from the default, you'll need a module definition file.

pascal, _pascal, __pascal

Category
Modifiers, C++Builder keyword extensions

Syntax

pascal ;
_pascal ;
__pascal ;

Description
Use the pascal, _pascal, and __pascal keywords to declare a variable or a function using a Pascal-style naming convention (the name is in uppercase).

In addition, pascal declares Pascal-style parameter-passing conventions when applied to a function header (parameters pushed left ot right; the called function cleans up the stack).
In C++ programs, functions declared with the pascal modifer will still be mangled.

cdecl, _cdecl, __cdecl

Category

Modifiers, C++Builder keyword extensions
Syntax

cdecl ;

_cdecl ;

__cdecl ;

Description
Use a cdecl, _cdecl, or __cdecl modifier to declare a variable or a function using the C-style naming conventions (case-sensitive, with a leading underscore appended). When you use cdecl, _cdecl, or __cdecl in front of a function, it affects how the parameters are passed (parameters are pushed right to left, and the caller cleans up the stack). The __cdecl modifier overrides the compiler directives and IDE options.
The cdecl, _cdecl, and __cdecl keywords are specific to C++Builder.

_fastcall, __fastcall

Category
Modifiers, C++Builder keyword extensions
Syntax
return-value _fastcall function-name(parm-list)
return-value __fastcall function-name(parm-list)


Description

Use the __fastcall modifier to declare functions that expect parameters to be passed in registers. The first three parameters are passed (from left to right) in EAX, EDX, and ECX, if they fit in the register. The registers are not used if the parameter is a floating-point or struct type.

All form class member functions must use the __fastcall convention.

The compiler treats this calling convention as a new language specifier, along the lines of _cdecl and _pascal
Functions declared using _cdecl or _pascal cannot also have the _fastcall modifiers because they use the stack to pass parameters. Likewise, the __fastcall modifier cannot be used together with _export

The compiler prefixes the __fastcall function name with an at-sign ("@"). This prefix applies to both unmangled C function names and to mangled C++ function names.
For Microsoft VC++ style __fastcall implementation, see __msfastcall and __msreturn.
NB:The __fastcall modifier is subject to name mangling.

TClientDataSet::AppendData and TClientDataSet::BeforeGetRecords

TClientDataSet::AppendData
Adds a newly fetched packet of records to those already stored in the client dataset.
void __fastcall AppendData(const System::OleVariant &Data, bool HitEOF);


Description


Use AppendData to add a newly fetched packet of records from the server application to the client dataset. Data indicates the packet of records to add. HitEOF indicates whether or not the application server encountered the end of the dataset when it fetched the records from the database server.

Most applications call GetNextPacket instead to fetch a packet of records and automatically add them to those already available. Use AppendData when fetching data packets directly from the application server rather than letting the client dataset fetch data.

TClientDataSet::BeforeGetRecords
Occurs before the client dataset fetches a data packet from the application server.

__property TRemoteEvent BeforeGetRecords = {read=FBeforeGetRecords, write=FBeforeGetRecords};

Description
Write a BeforeGetRecords event handler to send custom information to the client dataset’s provider. BeforeGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.
When the client dataset fetches data from the application server, the following events occur:

1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates the data packet.
4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.

5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler


Кения сафари, противомалярийные таблетки, индивидуальный тур, тур экономическим, бюджетным Сафари , Вопрос Кении Сафари, пляжный отдых,
Kenya Affordable Safaris

TClientDataSet::AfterGetRecords

TClientDataSet::AfterGetRecords
Occurs after the client dataset fetches a data packet from the application server.

__property TRemoteEvent AfterGetRecords = {read=FAfterGetRecords, write=FAfterGetRecords};

Description
Write an AfterGetRecords event handler to respond to custom information returned to the client dataset from a provider’s AfterGetRecords event handler. AfterGetRecords is part of the mechanism by which a client dataset and a remote provider communicate information about data fetching. When working with a provider on a stateless application server, this mechanism allows the client dataset and the provider to communicate persistent state information.

When the client dataset fetches data from the application server, the following events occur:

1.The client dataset receives a BeforeGetRecords event, where it can encode custom information into an OleVariant that is passed to the application server as the OwnerData parameter.
2.The provider on the application server receives a BeforeGetRecords event, where it can respond to or change that information before the provider creates a data packet.
3.The provider generates an OnGetData event where it can edit the data before creating a data packet, and then generates the data packet.

4.The provider receives an AfterGetRecords event, where it can encode custom information into its OwnerData parameter or respond to information from the BeforeGetRecords event handler.
5.The client dataset receives an AfterGetRecords event, where it can respond to the custom information returned by the provider in its AfterGetRecords event handler.

TClientDataSet::GetNextPacket

TClientDataSet::GetNextPacket
Retrieves the next block of records from the application server.

int __fastcall GetNextPacket(void);

Description


Call GetNextPacket to retrieve the next sequential block of records from the application server. To specify the maximum number of records to return in a packet, set the PacketRecords property before calling GetNextPacket. A packet is appended to those records already stored in the Data property.

GetNextPacket returns the number of records added to Data. If the return value is 0, the client application has already received all available records from the application server.

Warning:
If the client dataset uses a stateless application server, you must use a BeforeGetRecords event handler to ensure that the data packet returns the correct set of records.

TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit


dbclient

Description
TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a
-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.

NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.

The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.

__thread, multithread variables

Category

C++Builder keyword extensions

Description

The keyword __thread is used in multithread programs to preserve a unique copy of global and static class variables. Each program thread maintains a private copy of a __thread variable for each thread.

The syntax is Type __thread variable__name. For example

int __thread x;

declares an integer type variable that will be global but private to each thread in the program in which the statement occurs.

Using thread-local variables

The thread function and any of the routines it calls have their own local variables, just like any other C++ routines. These routines also can access any global variables. In fact, global variables provide a powerful mechanism for communicating between threads.
Sometimes, however, you may want to use variables that are global to all the routines running in your thread, but not shared with other instances of the same thread class. You can do this by declaring thread-local variables. Make a variable thread-local by adding the __thread modifier to the variable declaration. For example,

int __thread x;

declares an integer type variable that is private to each thread in the application, but global within each thread.

The __thread modifier can only be used for global (file-scope) and static variables. Pointer and Function variables can’t be thread variables. Types that use copy-on-write semantics, such as AnsiStrings don’t work as thread variables either. A program element that requires runtime initialization or runtime finalization cannot be declared to be a __thread type.

The following declarations require runtime initialization and are therefore illegal.

int f( );

int __thread x = f( ); // illegal

Instantiation of a class with a user-defined constructor or destructor requires runtime initialization and is therefore illegal:

class X {

X( );
~X( );
};
X __thread myclass; // illegal

Creating and using a client dataset

TClientDataSet is a dataset component designed to work without the connectivity support of the Borland Database Engine (BDE) or ActiveX Data Objects (ADO). Instead, it uses MIDAS.DLL, which is much smaller and simpler to install and configure. You don’t use database or ADO connection components with client datasets, because there is no database connection.
Client datasets provide all the data access, editing, navigation, data constraint, and filtering support introduced by TDataSet. However, the application that uses a client dataset must provide the mechanism by which the client dataset reads data and writes updates. Client datasets provide for this in one of the following ways:

Reading from and writing to a flat file accessed directly from a client dataset component. This is the mechanism used by flat-file database applications.
-Reading from another dataset. Client datasets provide a variety of mechanisms for copying data from other datasets. These are described in Copying data from another dataset.
-Using an IAppServer interface to obtain data from and post updates to a remote application server. This is the mechanism used by clients in a multi-tiered database application.

These mechanisms can be combined into a single application that employs the “briefcase model”. Users take a snapshot of data, saving it to a flat-file so that they can work on it off-line. Later, the client application applies the changes from the local copy of data to the application server. The application server resolves them with the actual database, and returns errors to the client dataset for handling

TClientDataSet
TClientDataSet implements a database-independent dataset.
Unit
dbclient

Description

TClientDataSet encapsulates a database-independent, distributed dataset. A client dataset can be used as a

-Fully-functional, standalone, flat-file dataset for single-tiered database applications. When used in this manner, an application uses the client dataset to read from and write to a user’s hard disk directly, without accessing a database engine.
-Client dataset in the client application portion of a multi-tiered database application.

NB:The two functions described above are not mutually exclusive. A multi-tiered application can be designed to support the option of working with data off-line, using the “briefcase” model. On site, the application uses TClientDataSet to communicate with the application server’s data provider. When a user works off site, the client dataset writes a snapshot of the data to the hard disk. The application works with this snapshot off site, with the client dataset acting as a flat-file dataset in a single-tiered application.

The client dataset can communicate with a data provider directly by calling the provider component’s methods. When used in a client application as part of a multi-tiered application, the client dataset passes all calls to the provider through the remote data module’s IAppServer interface.