<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE product SYSTEM "bag-1.0.dtd" >
<product shortname="odbf">
   <name>ODBF</name>
   <vendor>Leonid Schavelev</vendor>
   <currentversion>3.1</currentversion>
   <wikiname>OdBf</wikiname>
   <web>http://www.polytech.ivanovo.su/~leonid/</web>
   <email>Leonid@iname.com</email>
   <internalemail>Leonid@iname.com</internalemail>
   <shortdescription>Native VCL for access DBF
   files.</shortdescription>
   <sourceavailable>1</sourceavailable>
   <dataaware>None</dataaware>
   <querylanguage></querylanguage>
   <delphivers>1 2 3 4</delphivers>
   <cppbvers>3 4</cppbvers>
   <deployment>Compiles into your EXE.</deployment>
   <models>
      <local primary="1">Yes</local>
      <fileserver primary="0">Yes</fileserver>
      <clientserver primary="0"></clientserver>
      <webserver primary="0"></webserver>
   </models>
   <packages>
      <package description="Per developer, with source"
      price="$25" />
   </packages>
   <compatibility>
      <tool name="(Delphi) Database Explorer" compatible="Unknown" />
      <tool name="Ace Reporter" compatible="Unknown" />
      <tool name="InfoPower" compatible="Unknown" />
      <tool name="Orpheus (TurboPower)" compatible="Unknown" />
      <tool name="QuickReports" compatible="Unknown" />
      <tool name="RAVE Reports" compatible="Unknown" />
      <tool name="ReportBuilder Pro" compatible="Unknown" />
   </compatibility>
   <dataformats>
      <dataformat database="DBF" native="1" via="" notes="" />
   </dataformats>
   <vendordescription>
      <p>The whole power of Delphi's native tools for databases
      manipulation is not required in small single-user applications.
      To my mind, there are many cases when there is no need to
      depend on many IDAPI DLLs if your program works with few tables
      on your PC. That's why I rewrote my unit for DBF tables, which
      was originally created for Borland Pascal 7.0, in Borland
      Delphi. There are several distinction from the previous Pascal
      version 2.0, which was produced in January, 1996
      (odbfile2.zip).</p>
      <p>1. Since Delphi supports component library, I made TDBFTable
      a component instead of previous TDBF object). To my mind, it's
      more convenient.</p>
      <p>2. Pascal collections are substituted by list objects in
      Delphi. That's why I excluded iteration methods ForEach,
      FirstThat, NextThat, LastThat and PredThat from the TDBFTable's
      set of methods. But there are new methods and properties now
      for providing processing of records, and modification of
      previously written BP-applications will not be difficult.</p>
      <p>3. According to the same reason the structure of DBF tables
      is defined now by means of lists of field definitions, not by
      collections. Moreover, there is a new component TDBFStructure
      now, so you may define and modify structures manually at design
      time and by calling method DefineFields at run-time. Of course,
      you also may form structures dynamically from the code, as
      before.</p>
      <p>4. The support of memo fields is implemented. You may set
      data of unlimited size from memory buffers and files into memo
      fields and get data from these fields into memory or files.</p>
      <p>The current version 3.1 (July, 1999) has several new
      features in comparison with 3.0.</p>
      <p>1. Arbitrary blob data may be stored in memo fields now. In
      dBase III 1Ah symbol is treated as termination char in memo
      fields, so we must always take care of the absence of such
      symbols memo fields, otherwise the first one in the field would
      be estimated as its end. Text data never contain such symbols,
      but blob fields like images, archives and so on have not this
      limitation. In version 3.1 of ODBF you have 4 new methods:
      GetBlobToBuffer, GetBlobToFile, SetBlobFromBuffer and
      SetBlobFromFile. Arbitrary blob data can be encoded/decoded by
      them in/from pseudotext which is stored in memo fields.</p>
      <p>2. Problem of year 2100 was solved. In previous versions
      2100 was considered to be a leap year, date 2100/02/29 was
      admissible and procedure NextDate and function CountDays could
      return incorrect result. Boolean function LeapYear was added to
      ODBFTool unit because standard IsLeapYear function is not
      available in early versions of Delphi.</p>
      <p>3. Buffers for storing file names were increased. Now the
      size of full file name may be 254 bytes, in previous version
      maximum full name length was 80 symbols.</p>
      <p>4. Problem of pathnames with points was solved. In ODBF 3.0
      DBF-table with memo-fields couldn't be correctly opened by USE
      method if at least one point ('.') took place in the path names
      of DBF and DBT files (E. g., 'C:\MY.DIR\TABLE.DBF').</p>
   </vendordescription>
   <ourcomments>
         <p>ODBF is inexpensive and very lightweight - fine for very
      small projects. However, if you are putting together database
      software with a GUI, you should probably consider one of the
      competing products that supports data-aware controls. ODBF can
      be registered on-line.</p>
</ourcomments>
   <internalnotes>also supports D1</internalnotes>
   <lastupdated></lastupdated>
   <lastupdatedby>Kyle Cordes</lastupdatedby>
   <active>1</active>
</product>
