As a complement to SRTransport, Schema Research's data moving and manipulation powerhouse, SRBrowse queries data from your database, and lets you edit that data. It's a query tool, a simple extract tool, and an instant user interface. SRBrowse is aware of data relationships, helping you navigate between related data. SRBrowse connects directly to your database and presents rows of data. Or it presents objects as described with EOF's object-to-database map.

Browse & Edit

SRBowse lets you browse and edit data in your database. You can create new records, or change or delete existing records. The instant user interface it provides allows for easy access to all of your data and relationships.

Data Relationships

SRBrowse is aware of the data relationships in your database, and it lets you follow them from record to record. For instance, you can browse from invoice records to corresponding line item records, to product records all within an easy to navigate instant user interface. Even the most complex relationships are easily followed using SRBrowse.

EOF Models

SRBrowse works directly with your database, or it works through an EOF model. An EOF model is an object-to-database map. The model describes the Objects, and how they map to database tables and columns. The mapping is often 1-to-1 but at times, it can be complex. This supports the EOF developer, presenting them with objects rather than data records.

SRBrowse can load your compiled business objects, and it then becomes a true object browser/editor, which is much more capable than a record browser/editor. For example, you can code arbitrary business validation and processing into your business objects, and they perform their function operating inside the SRBrowse application.

Physical mode

When SRBrowse works with an EOF model, it presents the database as it is mapped by the EOF model, which may not look like the database at all. The Physical mode allows you to drop down from the object model, directly to the database structure, where table names and column names are visible, and joins are not abstracted.

Design Feedback

SRBrowse is valuable during the database design phase of a project. When data is captured for a new design, there is immediate feedback on that design enabling you to catch design issues early in development.

SRBRowse works directly from the database definition. Therefore changes in the database definition are automatically read by SRBrowse and reflected in the interface.

Instant UI

SRBrowse functions as an instant User Interface. It allows you to capture data before a user interface has been built for your database system, thus allowing you prototype reports, extracts and other time consuming tasks earlier in your project cycle. This feature, when coupled with SchemaE's ability to change a table's definition without deleting any data, makes for rapid database application development and deployment.

Read-only

SRBrowse can operate in a Read-only mode, which will not allow changes to the database. All manually entered SQL is rolled back to guarantee that the database isn't modified. Read-only mode can be set as a personal preference by users, or in a centralized manner eliminating the possibility of it accidentally being overridden. Of course, SRBrowse is required to follow the databases' own security policies for additional protection and security.

Database SQL

SRBrowse has an SQL window where you can enter any SQL statement and see the resulting data set. This functionality provides repeat querying for refinement. If SRBrowse is in Read-only mode, all SQL statements are rolled back, guaranteeing that the database isn't modified.

Query Qualifier

SRBrowse allows you to enter an EOF qualifier in each data window. An EOF qualifier is similar to an SQL WHERE clause. Of course, you can enter any SQL statement with a WHERE clause in the SQL window.

Database Diagrams

SRBrowse data windows can be launched from SchemaE database diagrams, either by menu command or by drag and drop.

Data Extracts

SRBrowse allows you to copy (as in copy-and-paste) rows or columns of data. You can then paste these rows into another application such as a spreadsheet or word processor. Comma Separated Values (CSV) format is used for these functions. Additionally, SRBrowse allows you to export records to a flat file, where you can choose your own field separator.

Duplicate Object

SRBrowse allows you to copy-and-paste objects/records. If you duplicate an object/record by copying and pasting it, you must be sure to change the primary key values before you save it (unless you have custom code in your business objects to handle this). You can also copy objects/records from one table/entity to another, in which case similarly named fields will be transferred. This works across database server types as well (i.e. Oracle to Sybase) which can eliminate the need for a special transport for small data sets.

Simple Reporting

SRBrowse allows the user to reorder and resize the data columns, change the sort order of the rows, specify a restricting qualifier, and choose a date format. These formatted data results can be printed for easy reporting.

Launching SRBrowse

SRBrowse windows can be launched from other applications. SchemaE and SRTransport are good examples. Your applications can be programmed to launch SRBrowse windows.

Records versus Objects

Internally, SRBrowse creates objects from database records (actually the EOF libraries do this). These objects are what is presented to the user and what is edited by the user. When changes are saved, appropriate SQL is generated for new or changed or deleted objects.

The internal objects sometimes are structured exactly like the database tables. This is the case when you connect directly to a database, or when you are in Physical mode. In this case, you can't tell you're editing objects. They just look like table records.

If SRBrowse uses an EOF model, then the internal objects will be structured differently from the database tables; possibly very different, but most often just a capitalization change. And foreign keys are usually replaced with object relationships.

Primary Keys

SRBrowse data windows require every table (entity) to have a primary key. If a table doesn't have a primary key, SRBrowse can't present it. Primary keys can be composite, i.e. made up of multiple columns. SRBrowse uses the EOF libraries (DLL's) even when it isn't using an EOF model. The EOF libraries require that every table (entity) have a primary key.

However, the SQL window allows you to submit arbitrary SQL and to view arbitrary data results. In that window, a primary key is not required.