What Is Northgate Reality RealWeb and How Does It Fit with Reality Multivalue Systems?
Northgate Reality RealWeb is a web-access layer for the Reality multivalue database, not a database in its own right. It lets browser-based clients read and write data held in Reality files, so organisations can put a web front end on an application that was originally built for terminal or character-based access. It is relevant if you already run Reality (or inherited a system that does) and want to expose that data without replacing the database first. It is not a route to a modern relational platform on its own, and it does not remove the need for the underlying Reality DBMS, its file structure, or its BASIC and ENGLISH tooling.
Where RealWeb sits in the Reality stack
Reality is a multivalue (Pick-family) DBMS: data lives in hashed files, records are dynamic arrays with attribute, value and subvalue delimiters, and application logic is typically written in a BASIC dialect with a query/report language alongside it. RealWeb does not change any of that. It sits above the DBMS and translates web requests into operations against Reality data.
That means three things stay true when you use it:
- The data model is unchanged. Records are still multivalue arrays, not tables with fixed columns. Any web layer has to handle repeating values and multivalued fields.
- Business logic stays where it is. If validation, calculations or workflow live in Reality BASIC programs, RealWeb-based screens generally call into that logic rather than reimplementing it.
- The DBMS is still the system of record. RealWeb is an access path, so availability, backup and licensing of the core Reality environment still govern everything.
A practical way to picture it: a customer service screen in a browser submits a customer number; RealWeb passes that through to a Reality subroutine or file read; the multivalue record comes back and is formatted into HTML. The database never becomes relational — only the presentation does.
Typical use cases
RealWeb-style access is usually chosen for one of these jobs:
- Browser-based data entry replacing green-screen forms, often for staff who expect a modern UI.
- Reporting and enquiry where users need read-only views of Reality data without a terminal emulator.
- Exposing legacy data to modern clients — an internal web app, a portal, or a service that other systems call.
- Extending reach to remote or occasional users who would otherwise need terminal emulation installed and configured.
The common thread is that the Reality application is still the centre of gravity and the web layer is a window onto it.
How RealWeb compares with other Reality connectivity options
| Approach | What it gives you | Trade-offs |
|---|---|---|
| Terminal emulation | Full access to existing character-based screens | No modern UI; per-user client setup; poor fit for web or mobile |
| RealWeb-style web layer | Browser access to Reality data and logic | Tied to the vendor layer; UI and integration work still needed |
| ODBC/JDBC bridge | Reality data visible to relational tools and BI | Mapping multivalue records to flat tables is lossy and needs care |
| Custom API / service layer | Precise control over what is exposed and how | Most development effort; you own maintenance |
The choice usually comes down to how much of the existing application logic you want to keep versus how much you are willing to rebuild. RealWeb preserves more of the existing investment; a custom API gives more freedom but shifts more work onto you.
Modernisation and migration paths
If RealWeb is no longer viable — for example because the vendor layer is unsupported, the skills are hard to find, or the business wants cloud or relational reporting — the usual paths are:
- Keep Reality, replace the access layer. Extract data through available bridges or APIs and build a new front end, leaving the DBMS in place.
- Migrate data out. Move records into a relational or cloud platform, flattening multivalue structures into tables. This is where multivalue-aware migration experience matters, because naive flattening loses the repeating-group semantics.
- Rehost and redevelop. Move the whole application to a supported multivalue platform or rewrite it, using the migration as an opportunity to redesign.
Each path needs an inventory first: which files, which dictionaries, which BASIC routines, and which reports are actually in use. Without that, migration estimates are guesswork.
Support and expertise today
Vendor and community support for Northgate Reality has declined, and specialist knowledge is increasingly held by individual contractors rather than large vendors. Nine Elms Solutions, a UK firm that described itself as primarily multivalue systems users and designers offering legacy data migration help, has ceased trading following the owner's retirement; the owner continues website development as a hobby through Internet Style. That pattern — deep multivalue expertise concentrated in a small number of practitioners — is typical of the Reality and wider Pick ecosystem now.
Practically, that means:
- Verify support status before committing to any RealWeb-dependent roadmap.
- Look for multivalue-specific experience, not general web development, when hiring for migration or integration work.
- Document your own system while the people who know it are still available.
If you are assessing a Reality system today, the useful question is not only "can we put a web front end on it?" but "who will maintain this in five years, and what is the exit path if they can't?"