InterBase is an SQL standards-compliant database. Starting with SQL92, all features added to InterBase strictly follow industry standards. With unicode support, InterBase is ideal for any character set and is widely used globally.
InterBase offers a range of SQL language features including multiple join and unicode.
Transactions and Multigenerational Architectures
When making a change in InterBase, you must first start a transaction. A transaction can be connected using multiple options, allowing for either a live view or a snapshot view of the data. This ability to have multiple view types of the data is thanks to InterBase’s being built using a multigenerational architecture.
Having a multigenerational architecture is exceptionally powerful when it comes to reporting. Having the ability to connect with a consistent snapshot of the database ensures that you are always comparing like for like. Equally important, the multigenerational architecture also ensures that readers don’t block writers from making changes, increasing database scalability, and also enabling other key features like online backup and Change Views.
Finding out something is changed in a central database is a typical concern of developers. InterBase Events enable a live time alert to connected clients that something has changed. Alerts are sent immediately after the transaction making the change is committed. This saves on CPU-intensive database polling, thus increasing database scalability. When run alongside Change Views, Events allow for the fastest way to fetch data changes by collecting just the delta of what has changed from the server, additionally reducing network traffic and associated costs.
The award-winning Change Views is a patent-pending feature of InterBase that allows developers to identify what has changed in the database. Working with Change Views is simple; running the same SQL statement in subsequent transactions will return only the delta. This makes fetching and identifying changed data very simple.
Change Views works with the multigenerational architecture of InterBase to speed up applications and lower network traffic and costs by finally allowing briefcase data to become always relevant, removing the need to fetch the same data time and time again.
Managed Fields Definitions/Domains
InterBase domains allow you to define a specific field type (e.g., VarChar(20)/Integer, etc.) and define properties for that field (e.g., Can it be null? or can it define a range of values that can be passed in?). Using InterBase domains allows you to easily manage the same field type across your database. This simplifies adding the same type of field everywhere, and as it is defined once, so you can easily update the field type across the database if requirements ever change.
InterBase stored procedures allow you to compile server-side functions into your database engine that enables easily updatable business logic that clients can call. This could be to ship an order or add a new customer—the options are endless. You can also run select statements against stored procedures to return a custom layout of data. You can even build SQL statements inside your stored procedures to run, based on data passed in or fetched.
Triggers are a powerful feature with a variety of uses. Among the ways that triggers can be used are:
- To make correlated updates - for example, to keep a log file of changes to a database or table.
- To enforce data restrictions so that only valid data is entered in tables.
- Automatic transformation of data - for example, to automatically convert text input to uppercase.
- To notify applications of changes in the database using event alerters.
- To perform cascading referential integrity updates.
Generators allow you to fetch sequential numbers that are typically used for primary keys within InterBase. Generators work across database transactions, and InterBase will not assign a duplicate key. InterBase generators allow you to enable the database to be responsible for the production of key values centrally in the database.
InterBase allows you to build database logic to manage the data being passed in. Working alongside stored procedures and triggers that happen before the data is updated, you can raise a custom exception from the server if bad data is passed in.