FIB DAC 2.02

In category

DB-Aware Components > Direct DB Access > Interbase and Firebird

Description

The suite of eight data-aware components:

• TFIB_Database
• TFIB_Transaction
• TFIB_Dataset
• TFIB_UpdateSQL
• TFIB_Query
• TFIB_StoredProc
• TFIB_Generator
• TFIB_CreateAlterDrop

for direct access of Firebird databases (Interbase also, but tested only on Interbase ver. 7.5). The components are based only on my own, not seldom non-standard, ideas. I have created these components with minimum programming code (all DCUs weigh ONLY 308KB). Wherever the original Borland code was not optimal I have overriden it, but generally I’ve tried to take the maximum advantage of Borland code.

You will be amazed at the potentiality and efficiency of FIB DAC components that set a new standard, unattainable for other compomnents being usually heavy, overgrown and complicated. TFIB_Dataset is the only dataset component that besides simplest (and slowest together) static data access method, supports dynamic data access and partial (growing) records fetching (IN MANY CASES EVEN HUNDREDS TIME FASTER THEN STATIC METHOD; see Readme.txt and Readme_comparision.txt for more details).

Here are some features of the most important component, i.e. TFIB_Dataset:

• the fastest Firebird Servers data access (when Unidirectional = True, also as replacement for all dbExpress drivers; when used as data supplier for ClientDataSet, TFIB_Dataset automatically sets Unidirectional to True and allocates 0 bytes for fetched records)
• one component for all recordsets, ReadOnly and not ReadOnly i.e. physical Tables
• You can also select from stored procedures; published property ProcName lets You choose required procedure (among procedures that return any fields) from the drop-down list at design time
• published property SQLStatement is divided into five sections: SELECT...FROM... , WHERE , GROUP BY , PLAN , ORDER BY
• statements based on one table with joined other recordsets ARE TREATED AS TABLES i.e. NOT READONLY DATASETS
• three strategies for accessing of data:
  • daStaticAccess (nonTable Datasets are always accessed in this manner) - all fields of fetched records are stored in memory; this is the conventional and the slowest method of data access)
  • daDynamicAccess - purely record identifying fields are stored in memory (if there is no primary/unique key for the table or size of primary/unique index > 8, RDB$DB_KEYs are stored)
  ESPECIALLY RECOMMENDED FOR BIG TABLES WITH LOTS OF FIELDS
  • daPartialFetch - all fields are stored in memory but records are fetched and appended in progressive manner during each call of one of search method (i.e. Locate, LocateNearest, FindKey, FindNearest) so You have the guarantee that searched records are fetched
  ESPECIALLY RECOMMENDED FOR HUGE TABLES
• each table based TFIB_Dataset, immediately after it is opened, returns the real RecordCount in the rowset and can be browsed from bottom without any time delay
• ingenious algorithms for FASTEST exact and nearest record locating
• MasterSourceFields are defined regardless of IndexFieldNames, it means You can sort detail Dataset as You want without loosing link to MasterSource
  • in dsInsert state, TFIB_Dataset assigns for You MasterFields values to appropriate LinkedFields automatically
  • You can use Borland Field Link Designer at design-time to set relationship between master-detail fields
• allowed multiple reference for same parameter (listed only once in Params property), for example: SELECT * FROM PERSONS WHERE (:BirthPlace_ID = 0 OR BIRTHPLACE_ID = :BirthPlace_ID) AND (:BirthDate = 0 OR BIRTHDATE >= :BirthDate)
• records are stored with minimum allocation of memory (each null field value takes just one bit of memory and string fields occupy only actual length)
• fully supported array fields; each array field is created as TFIBArrayField (descendant of TArrayField) and is compatible with TCustomDBGrid descendants
• public property IndexFieldNames lets You sort dataset both in ascending and descending order
• when performing Delete UpdateStatus returns usDeleted and after deletion succeded DataEvent(deUpdateRecord, 0) is sent before Resync is called, so deleted Record is at this moment still in the Buffer retuned by ActiveBuffer
• fully supported EMBEDED server; see Demo app
• and much more; see Readme.txt for more information
• see History.txt for changes

Informations

• Status: Trial (work while IDE is running)
• Source: FNC
• Size: 968262 - 984570kB

Platforms:

• Delphi 2006 (Win32)
• Delphi 2007 (VCL)
• Delphi 6
• Delphi 7

Downloads

• Delphi 2006 (Win32) , Delphi 2007 (VCL)
• Delphi 6
• Delphi 7