|Home » Technical Support » DBISAM Technical Support » Product Manuals » DBISAM Version 4 Manual for Delphi 6 » Before You Begin » Changes From Version 3.x|
|Table Signatures||Every table is now stamped with an MD5 hash that represents the hash of a "signature" that is specified in the EngineSignature property of the TDBISAMEngine component. In order to access any table, stream, or backup created with a specific engine signature other than the default requires that the engine be using the same signature or else access will be denied. Please see the Customizing the Engine topic for more information.|
|Locale IDs||The language ID and sort ID values (Word values) for a table in 3.x and lower have been replaced with one single locale ID (Integer value). This causes a change in the TDBISAMTable RestructureTable method, which has been renamed to the AlterTable method to maintain consistency with the ALTER TABLE SQL statement (see below). Also, the LanguageID and SortID properties of the TDBISAMTable component are now one LocaleID property. Finally, the SQL LANGUAGE ID and SORT ID keywords have been replaced with the single LOCALE keyword in SQL statements, and some of the language identifiers (string values) have been modified to reflect the change to a locale instead of a language identifier.|
|Table Encryption||The default table encryption in prior versions of DBISAM was weak XOR encryption and, although it was fast, it was also easily broken. The table encryption in version 4 is Blowfish encryption that is not easily broken. All table passwords are stored as MD5 hashes encrypted with the same Blowfish encryption. Please see the Encryption topic for more information.|
|System Fields||There are two new "system" pseudo-fields in every table called "RecordID and "RecordHash". These fields can be indexed, filtered, etc. but do not show up in the field definitions for the TDBISAMTable or TDBISAMQuery components. RecordID is an integer value (4 bytes) representing the fixed "row number" of a given record. RecordHash is an MD5 binary value (16 bytes) that represents the hash of a given record. If you upgrade a table that already has a field named the same as either of these fields, your field will be automatically renamed by the UpgradeTable method or the UPGRADE TABLE SQL statement to '_'+OldFieldName. In other words, an underscore will be added to the front of the existing field name.|
|Auto Primary Index||In version 3.x and earlier you could have a table without a primary index. In version 4, if you do not define a primary index when creating or restructuring a table, DBISAM will automatically add a primary index on the system RecordID field mentioned above.|
|BLOB Compression||You may now specify compression for BLOB fields when creating or restructuring a table. The compression is specified as a Byte value between 0 and 9, with the default being 0, or none, and 6 being the best selection for size/speed. The default compression is ZLib, but can be replaced by using the TDBISAMEngine events for specifying a different type of compression. Please see the Compression and Customizing the Engine topics for more information.|
|Maximum Field Size||The maximum size of a string or bytes field is now 512 bytes instead of 250 bytes.|
|FixedChar Fields||String fields that are of the ftFixedChar type do not automatically right-trim spaces from strings assigned to them as they have in the past. String fields that are of the type ftString still treat strings like VarChars and right-trim the strings assigned to them. For example, assigning the value 'Test ' to the two different field types would result in the following:|
This is useful for situations where you want to keep trailing spaces in string fields.
|GUID Fields||GUID fields are now supported and are implemented as a 38-byte field containing a GUID in string format.|
|AutoInc Fields||Auto-increment fields are now always editable and you may have more than one autoinc field per record, with each field incrementing independently. Because these fields are editable, the SuppressAutoIncValues property has been removed from both the TDBISAMTable and TDBISAMQuery component and the NOAUTOINC clause has been removed from the SQL statements. The way autoinc fields work now is that they will auto-increment if a value is not specified for the field before the Post operation (field is NULL), and will leave any existing value alone if one is already specified before the Post operation.|
If you do not want an end user to modify any autoinc fields directly then it is extremely important that you mark any autoinc fields as read-only by setting the TField ReadOnly property to True before the user is allowed to access these fields.
|Descending Index Fields||You may now specify which fields are ascending or descending in an index independently of one another. This change also modifies the AddIndex method of the TDBISAMTable component slightly as well as the TDBISAMIndexDef objects used in creating and altering the structure of tables. With SQL you can simply place an appropriate ASC or DESC keyword after each field specified for an index definition in a CREATE TABLE or CREATE INDEX statement.|
|Index Page Size||You may now specify the index page size when creating or altering the structure of tables. This changes the TDBISAMTable AlterTable method slightly as well as the CREATE TABLE SQL statement syntax. Also, there is a new IndexPageSize property for the TDBISAMTable component. The minimum page size is 1024 bytes and the maximum page size is 16 kilobytes.|
The index page size affects the maximum key size that can be specified for an index, so if you try to index very large string fields you may get an error indicating that the index key size is invalid. Also, regardless of page size the maximum key size for any index is 4096 bytes. Finally, the maximum number of fields that can be included in a given index has been expanded from 16 to 128 fields. However, the number of indexes per table is still only 30 indexes and has not changed.
The TDatabaseRight type has also been expanded to include new rights for backup (drBackup) and restore (drRestore) of a database, as well as rights for performing maintenance (drMaintain) on a database like repairing and optimizing tables and renaming objects in a database (drRename).
This was done to give the developer more control over which condition he/she was responding to, especially when it comes to transaction lock timeouts.
MyColumName LIKE 'Test%'
SELECT max(MyField) FROM MyTable
SELECT * FROM MEMORY biolife
SELECT * FROM "\Memory\biolife"
SELECT * FROM MyTable WHERE MyColumn LIKE '100\%%' ESCAPE '\'