• Embarcadero has certified Interbase-XE3™ for native 32-bit and 64-bit.
• Any Client who has a valid Interbase Support-Maintenance Contract is eligible for the upgraded versions of Interbase at no additional charge.
• Note:  Clients will receive notification via email directly from Embarcadero on these matters... and so it's important you watch for emails from Embarcadero (both inbox and spam) -- and since these notification emails don't come to us, Clients themselves are solely responsible for getting-reading-acting on these emails.

Journaling -

Journaling with Write Ahead Logging (WAL) technology improves VLDB management, and facilitates disaster recovery.

• Journals are short lived files that represent all of the changes required to complete all transactions that occur within their checkpoint timeframe. When you turn journaling on, you specify the checkpoint in terms of the number of changed pages and/or the amount of time that has passed, and also a file size (length).

Journals work like this:

• Forced writes are turned off to the database file, all writes are now asynchronous
• Forced writes are turned on to the journals, all writes are now synchronous
• As the pages are changed, they are written to the journals
• A separate thread is processing these page updates and applying them to the database in a more efficient manner than normally available (clustering page updates, etc)
• At Checkpoint, all changes are flushed to the database to ensure consistency in the database file
• At LENGTH, the journal files roll over to a new file. The old one is kept and reused for the next rollover (it is renamed and overwritten).
• If the server dies before the journal contents are written to the database file, on startup, a short term recovery is started and the database is bought up to date.

Journals increase performance as long as they are kept on a different disc from the main database because:

• The change to delayed writes for the database
• The greater level of intelligence available to the database when writing pages back to the disc - it is able to amalgamate consecutive pages perhaps from different transactions and write them sequentially
• All writes to journals are being done sequentially rather than randomly

Journaling provides a mechanism to increase performance with multiple discs. Journals provide a far greater performance improvement in situations where the database has been put into forced write mode because of reliability concerns. Typically this is done in small organizations where there is no battery backup or RAID set ups. Forced writes operate at ten times slower than delayed writes, thus making journaling an attractive option while retaining the same level of reliability.

Database and Column-level Encryption - 

Interbase-XE3™ now supports the use of either weak (DES) or strong (AES) encryption to encrypt a Database and/or individual columns in a Database table, providing ultimate security for data and communications between Servers and Clients.

Over-the-Wire (OTW) Network Encryption -

Typically, data encrypted at the database (or column-level) is not encrypted during the transmission process.  OTW encryption, however, allows us to do just that: encrypt data as it is communicated over a network from a Client to a Server.  With OTW encryption, Abacus 21 can encrypt network transmissions with the same strength as was used to encrypt the database or columns.  You can use weak or strong encryption, though to use strong (AES) encryption, you must obtain an optional strong encryption license, available at no additional charge.

Encryption of Backup Files -

When we encrypt a Database and/or any of its columns, we also can encrypt the Backup files for that Database.   Then we decrypt the Backup files during the Restore process.  This adds an additional layer of protection to your data.

Interbase-XE3 To-Go™ Edition -

Abacus 21 also offers the new Interbase To-Go™ Edition -- a small, portable version of the Desktop Edition. Target applications for the To-Go Edition include small devices and public kiosks.  Used in the To-Go edition form, InterBase does not have to be separately installed on any Server or End-User Workstation.

Journal Archiving provides disaster recovery in the event a database becomes unavailable due to hardware or software failures that may make the primary database permanently inaccessible

Journals add to the reliability of your system when Journal Archiving is turned on. Journal archives are designed for long term recovery, and when activated do two things:

• They take a copy of your database as of the time you created the journal archive (a database dump, the same technology that is used for the incremental backups.
• When a journal hits its length, it is archived instead of being “deleted” (re-used). The journal is copied to the Journal Archive directory.

Journaling Summary

By using the new journaling capability, sites that use InterBase can dramatically increase their reliability - even in single server, single disc situations. Journaling is typically considered a VLDB capability, but it need not be.  Even small Servers with the addition of a cheap second disc can achieve dramatically greater reliability for their data where only catastrophic failures (such as destruction of the server) will result in data loss.

Point-in-Time Recovery -

Point-in-time-recovery allows journal based recovery based on timestamp for greater recovery flexibility.

Point-in-time recovery allows you to recover to a specific point in time if you wish - you just specify the time when recovering the database and it will apply all transactions up to that point.

On-Line Dump -

On-line Dump provides Backup for seamless incremental Backup.

The Incremental Backup (on-line dump) feature is a physical backup mechanism. It backs up the physical pages of the database to “dump” files.  The incremental backup feature ensures that the output dump files represent the on-disk state of the database as of the instant the online dump was started, so transaction and page consistency are maintained in the process.

You can use the incremental backup as a staging area from which a logical GBAK can be performed, so that your production database is not adversely affected.  To do this, send the on-line dump to a remote machine and do the logical GBAK backup on that remote machine. This will also allow you to run a database validation because validation requires exclusive database access, which cannot be obtained on a production database unless that database is shut down.

Additionally, this feature allows you to create incremental dumps that write only those database pages to the dump files that have been modified since the last time a full/incremental dump was successfully completed. It also provides a means for you to move or copy a multi-file database to a different location. This was not possible previously because there was no way to modify the encoded file names stored on the primary and secondary header pages of the database files.

Batch Updates -

Batch Updates allow sending a group of SQL statements, reduces the network traffic resulting in improved performance, especially in LAN and WAN environments

Batch updates is a new feature in InterBase 2007 which allows you to put a large amount of DML together in one bundle (up to 2 GB) and send it to the InterBase server. The client then gets back an array of responses. The reason this is faster is that there is no back and forth for each statement between the client and the server, and the server is able to “look-ahead” to make better judgments about what the client wishes it to do.

Additional New Features -

• Hyper threading support for Intel® Pentium® 4 and Intel Xeon® processors
• Thread-safe client library-enhanced stability and improved performance for InterBase® clients
• Multi-generational architecture enables unparalleled concurrency between readers and writers
• Native multi-threaded server with background garbage collection and multi-user page buffer management
• Scalability from embedded, single-user applications to enterprise demands
• Immediate automatic recovery from system failures
• Garbage collection improves response and throughput
• Improved memory management allocation algorithms
• Stored procedure and trigger cache management
• Sort buffer cache management

Thread-private Latch Cache for enhanced SMP scalability

Reasons to Upgrade to Interbase-XE3 -

Durability to protect data and sustain high availability:

To further improve availability, Interbase-XE3™ offers new enhancements for protection against failures and increased disaster recovery options through log-based journaling for short-term recovery, and journal archiving for long-term recovery in the occurrence of hardware system failures. In addition, Interbase-XE3 introduces Online Dump of database files and Point-in-Time Recovery from archives.

The portable, international, cross-platform database allows for growth and flexibility:

Interbase-XE3™ Server Edition is certified to run without modification on Windows®, Linux, Solaris™, and Mac OS® X. This enables deployment to a wide variety of platforms without having to rewrite code. The database is fully portable between platforms, and also from InterBase SMP 2007 Desktop Edition to Interbase-XE3 Server Edition, allowing for flexible deployment. In addition, Interbase-XE3 supports international deployment for international character sets, including the latest Unicode, UTF-8 and UCS2.Framework components as well as other updates and enhanced documentation.

When performance matters:

Interbase-XE3 is one of the fastest native databases available, and through support for SMP (symmetric multiprocessing) it scales to multiple CPUs, including multi-core CPUs. Performance enhancements and optimizations have been added in a number of areas, such as batch updates, query optimizations, and OLTP improvement via journaling. InterBase implements a multi-generational architecture providing unique versioning capabilities that result in high data availability for transaction processing users and decision support users—simultaneously. Support for multiple simultaneous instances of InterBase on the same machine provides application isolation and load balancing.

Embed–Deploy–Relax:

Interbase-XE3™ combines simple installation and automatic crash recovery, with a self-tuning engine that makes it well suited for embedding. It is ideal for ISVs, OEMs, and VARs who require a database that is very compact in memory and disk size without compromising sophisticated features to support high-powered, business-critical applications. And, unlike many other enterprise databases that require expensive ecosystems of support and maintenance, Interbase-XE3™ is virtually maintenance free

Built for Developers:

Developers using CodeGear RAD Studio, which includes Delphi® and Delphi for .NET, and C++Builder®, as well as JBuilder®, 3rdRail and other tools can leverage a wide range of standard database connectivity options through ODBC, JDBC, ADO.NET, and IBX. Transaction monitoring facilities provide developers with granular database controls for viewing, starting, stopping, and rolling back transactions, processes, and queries. InterBase, compliant with SQL92 standards, offers developers everything they can expect from an SQL database: triggers, stored procedures, and views, as well as advanced concepts such as domains and event alerters.

Other Related Server Recommendations:

• Appropriate RAID, Duplex, Mirroring
• Appropriate Anti-Virus protection
• Appropriate Internet Access
• Appropriate Backup Provisions
• It is recommended that the Server be a 'name brand' (not a 'clone' or 'white box').  This is the foundation of the system and is where you should put your money -- and investment in better performance here translates to better performance thoughout the entire network.
• The Interbase Server should not generally be run on a Citrix Server.
• Network 'switches' are preferred to Network 'hubs' to better accommodate network traffic.

Abacus 21 System 441 in a Multi-Location Environment: top

Abacus 21 is a totally-integrated system that provides real-time updates between modules and real-time availability of information to Users.  This is typically accomplished by means of a central database where all information is retained.  In a multi-location environment, it may be beneficial to have additional Servers locally residing at the remote site for a variety of purposes -- for printing services, credit card authorization, or for non-Abacus purposes.  But normally the Abacus 21 System 441 database must reside in a single centralized location.

The remote Workstations will carry their own versions of the programs so that running programs will not create unnecessary network traffic... but they must be able to access the central database through the network.  If for some reason fast network connectivity is not available, then the Workstations can be configured as Thin-Clients by means of Terminal Services or Citrix in order to achieve good system response.  (Of course Thin-Clients are usable in the local environment -- and many Network Administrators prefer this architecture for ease of workstation configuration and support.)

In certain multi-Property (or Facility) scenarios that are separate (but related) Business entities, it might be desirable to set up separate 'independent' Servers-Databases -- perhaps tangentially linked to a Corporate Server... but, on these occasions, specialized software is needed from Abacus 21 to 'synchronized' those elements of operation that must "bridge" across boundaries.

Abacus 21 can also run within a Cloud-Computing Environment; call for details.

Setup Recommendations: top

Interbase & Abacus Server Install should not be run on Citrix or Terminal Services Servers used to host System 441 Client.

• It is common practice to setup Database Servers as dedicated Servers.
• It is common practice to setup Citrix or Terminal-Services Servers as dedicated Servers for hosting client programs only.
• This avoids performance & resource conflicts between Remote Users (Client Programs) and Server programs.
• Having two dedicated Servers also makes Upgrades easier.

Installation on Drives:

• Interbase can be installed on the C: drive of Servers -- but Abacus 21 Software should be installed on another drive letter such as D: or E: which is already typical among our Clients.
• It is common practice that C: drive partitions are rather small compared to other partitions.  This is because C: is expected to have mostly Operating System programs and minimal installations of other critical programs.
• For the best performance, the System 441 Server should be installed on a separate physical disk from the Operating System.

Miscellaneous Performance Notes: top

Servers should have (or be able to accommodate) at least two (or more) physical Processors (up to Quad-Core each).

• This provides the ability of utilizing additional Processor Licenses for Interbase.
• This also provides the ability for Abacus Server programs to have their workload distributed among Processors by the Operating System.
• Servers should have 2GB or more of memory.
  • This allows the possibility of increasing the database memory size to improve performance.
• Servers should have On-Line battery backup.
  • In case of power failure, this would allow the Server to shutdown properly... and significantly reduce the possibility of Database corruption.
• The more physical storage drives the Server has the better that Abacus 21 can configure System 441 to improve performance.  (Storage drives can be hard drives, RAID, or Ram Disk, etc...)
  • Installing the System 441 Server on a dedicated storage device will generally enable better performance -- as it would not have to compete with other programs for the same storage device.
    • This should include disabling the virtual memory swap file on the disk where the System 441 Server is installed.
    • Note:  If there is only one physical disk on the Server, then the swap file should not be disabled.

There are many possible storage configurations that affect performance:

• A highly performance-efficient hard drive configuration for an Interbase Server could be the following:
  • Dedicated Disk 1 - Server Operating System & Interbase Installation (includes Security Database Access)
  • Dedicated Disk 2 - Server Operating System Swap File
  • Dedicated Disk 3 - Interbase Sort File (perfect for RAM Disk type)
  • Dedicated Disk 4 - System 441 Server Installation & System 441 Database
  • Dedicated Disk 5 - System 441 Server Temporary Files (perfect for RAM Disk type)
  • Dedicated Disk 6 - System 441 Backups (ibk)
• The 'typical' configuration for an System 441 & Interbase Server is the following:
  • Dedicated Disk 1 - C: drive
    • Server Operating System & Server Operating System Swap File
    • Interbase Installation & Interbase Sort File
  • Dedicated Disk 2 - D: or E: drive
    • System 441 Server Installation & System 441 Database
    • System 441 Server Temporary Files
    • System 441 Backups (ibk)
• The 'worst' performing hard drive configuration for a System 441 & Interbase Server seems to be the following:
  • Dedicated Disk 1 -
    • Server Operating System & Server Operating System Swap File
    • Interbase Installation & Interbase Sort File
    • System 441 Server Installation & System 441 Database
    • System 441 Server Temporary Files
    • System 441 Backups (ibk)

Other things that can negatively impact performance:

• Antivirus scans of Databases or Database Backups as they are being modified.
• Other d\Database system databases being installed on the same drive as the System 441 Database -- like MSSQL Server.
• An active Windows swap file on the same drive as the System 441 Database.
• Disk file fragmentation.

Disk Space  top

The minimum Disk Space requirements for Abacus 21 Programs (System 441, with an 'empty' database) are:

• Server - 200 MB
• Client - 200 MB (if not a Citrix-TS Workstation)

One portion of the 'Disk Space' will be occupied by Client's data (for which we have no good way of 'predicting' Transaction Intensity, Image Libraries, History Retention, and Purge Frequency-Depth the Client will desire, encounter, or experience).

If the Client anticipates an Abacus Application database size exceeding 2GB, then the Harddrive should be formatted as NTFS rather than FAT32.

The other portion of the 'Disk Space' will be occupied by whatever else the Client has on the Server or Workstations -- in terms of Operating System related things, Utilities, Office Automation software, Interfaces, 3rd-Party programs (and all their associated data -- and 'traffic').

The Client needs to make their own determination of their overall Installation disk space requirements.

Report Printers  top

Although Abacus 21 does not provide nor endorse any particular Report Printers.

The most important factors to consider when selecting a Printer for compatibility with Abacus 21 applications are that they support PCL 5, 16.67 Pitch, and 66 Lines-per-Page.  (Note that Ink-Jet printers do not support PCL code -- nor do they naturally support BarCode fonts.)

If you are still unsure of the compatibilty of a Printer, you can make arrangements to ship it to Abacus 21 for testing (Hardware testing fees apply).  If you are intending to buy a new Printer, we suggest that you make an arrangement with your Hardware provider to 'return' a newly-purchased Printer that turns out not to work.

Abacus 21 no longer supports the older-style 'band' printers.  Also, continuous-form Dot-Matrix Report printers are not supported.  (Contact Abacus 21 for further details.)

• It is an unfortunate fact of technical life when dealing with Point-of-Sale, Inventory, and other Peripheral Devices -- such as Touch Screens, Touch PC's, Receipt-Ticket Printers (including associated Cash Drawers and portable ones), Prep Printers, Handheld POS Units, PDA's, BarCode Printers, BarCode Portable Scanner-Recorders, RF-Devices, Magnetic Stripe Readers, Fingerprint Scanners, Signature Capture devices, Photo ID & Gift Card & Wrist Band Printers/Encoders, Customer Displays-Kiosks, Weigh Scales, etc. -- that these Devices sometimes behave dramatically different from brand-to-brand and model-to-model... and sometimes differently between Parallel vs. Serial vs. USB vs. Ethernet... ... and sometimes differently with respect to Workstation or Server Operating Systems (including Terminal Services situations) ... and then sometimes differently because of different 'manufacture date' production runs .

• Moreover, Abacus 21 Applications that utilize these devices are sophisticated and intertwined.... consequently we must be extremely careful which exact combination of peripherals involved in an Installation and the software-hardware-driver configuration thereof in order to insure that all aspects of the system will perform appropriately.

• Abacus 21 will not guarantee system performance with these types of Peripherals that are not purchased from Abacus 21.  Any diagnosis, research, repair, system reconfiguration or data correction activities associated with resolving issues associated with this topic will be handled on an 'as able to' basis for a fee of $150 per hour.

• Existing (or Client-procured) peripherals of this nature must meet Abacus 21 compatibility specifications.  With prior agreement with a Client, these units may need to be tested at Abacus 21's Buffalo Office (currently priced at $150 per hour) in order to confirm initial compliance.  These items may need to be sent to the Buffalo Office at least 30 days prior to the anticipated go-live Date.

Policy & Procedures on Testing and Approving these Devices:

• The pertinent Abacus applications that might be able to utilize these  Devices have a wide variety of  of Application Software functionality, Software-Hardware Driver pairings, and Hardware Setting configuration settings... and all permutations of them need to be checked out.
• The Software-Device Driver sets and our internal Software logic/settings need to be aligned properly for the Device to operate appropriately -- and making the Device behave properly may involve new programming (or Driver development) and testing on our side.

As our Contracts state, Abacus 21 does not guarantee the performance of any Printers (or other POS devices) -- either initially, or in future Release levels -- that are not purchased thru Abacus 21 (and hence 'certified')... for the above types of reasons.... and because Abacus 21 has leverage with its suppliers/manufactures for those hardware or software components purchased via Abacus 21 to have them assist us and the Client in the diagnosis and rectification of any problems that crop up.

That said, Abacus 21 does offer a service to test and certify these types of Peripheral Devices (for Applicational suitability) upon Client request:

• The Client purchases one of the 'previously un-certified' Devices (perhaps via Abacus 21) and has it to Abacus 21.
• Abacus 21 would spend up to 2-Hours doing some initial tests ($300) on it... and let you know the results at that point.
• If the tests on the Device are "unsatisfactory" we would ask you if you would like us to 'continue to try to get it to work' or 'bail'.
• If the tests are "successful", then we offer the Client two choices:
  • Have the Device shipped back to the Client... with the Device being declared 'certified' for Abacus 21's current Release (only).  Client pays Shipping-Insurance costs.
  • Leave the device with Abacus 21 perpetually... in which we will insure it is compliant with current and future Releases (assuming the Client does not change the operating environment).

• Abacus 21 Hardware Peripheral prices include all the appropriate Operating System and Abacus 21 Application Software device Drivers.  Use of 3rd-Party products may require acquisition-configuration of the requisite Abacus 21 Drivers.

• 'Interference' can arise from the AV program's mis-interpreting one of Abacus 21's files as being bad and inactivating it -- or the AV program could be taking too long to scan files, thereby slowing down the system.

• Anti-Virus should be told to ignore the *.ib files:

  • Since these database files change frequently they may be subject to more frequent scans.

  • Scanning while the database is in operation may cause interference.

  • Abacus 21 has noticed an improvement in performance when the AV is told to ignore the database (*.ib) and database backup (*.ibk) files.

For further System 441 Requirements for operation, click here.

The suggested minimum requirements guidelines expressed above are merely intended to be generic -- and may vary based on the Client's own particular general environment, overall computing needs, and specific combination of Abacus 21 applications & devices.  Please check directly with Abacus 21 regarding the particular items you are intending to implement.

top