Setting up applications

No Programming!

SeriousB requires no programming though it has the flexibility of a
relational database program, most of which do require programming. It
offers the simplicity of an "application generator" program for
setting up most capability. It assumes the user has no prior database
experience and avoids traditional database terminology and procedures.
For complex or unusual capability, it offers "expansion signals" in
all aspects of the set-up job. These are usually single characters or
words added to the simple settings and instructions. This way, you can
set up your business right away without using this extra layer of
capability, perhaps without all the conveniences of a commercial
application. But all the time you are using the same basic settings
and instructions you will use to add those conveniences and extra
capability later.

The SeriousB online manual lists each basic setting or instruction
with an explanation and examples, followed by the list of special
signals. One chapter is devoted to an organized list of examples and
explanations for signals used in the most complex setup jobs.

This ability to expand incrementally on a simple design is impossible
with most database programs due to speed. SeriousB is extremely fast
due to several unique design features Micromiser developed in the
1980s to provide business capability on 8-bit computers. Examples are
separate dated and undated database organization, intrinsic indexing,
and block I/O with variable length fields and records. One nice result
is databases that take up 1/4 the disk space.

Ideal for beginning consultants

Whether or not you are a programmer, if you have business experience
and can adopt a "business operator" mind-set, SeriousB is ideal for
starting your consulting business. We have used it in our "Easy
Genius" Consulting Course. We no longer maintain Easy Genius, but most
of the content will eventually be available in our Infobase.

Licenses

If you will provide SeriousB applications to others, each client must
register a separate copy of SeriousB at each client location (i.e.
each network) and pay the registration fee, currently $299.

xBase Comparison - Review Guide

SeriousB Primer for xBase programmers

The rest of this document serves three purposes: 1) A description of
how the SeriousB program works compared to xBase-type languages and
application generators, 2) A primer for those experienced with these
to get started with SeriousB, and 3) A good starting point for a
review of the SeriousB program by reviewers experienced with these
database platforms.

Advantages compared to most database programs and app generators

* Local (LAN) client/server free! (no database engine to buy, no
licences)
* No third-party product needed for reports, deployment, etc.
* No learning curve for local client/server - It's invisible and
automatic.
* Easiest network setup on the planet! Just two settings: the station
name and the application drive letter.
* Don't need to deploy separate database engine (integrated with
SeriousB)
* Don't need to cache data entry. SeriousB intelligently updates in
real-time
* Store an invoice (etc.), next invoice (etc.) knows the new stock
levels--on any station.
* Inventory calculator provides accurate stock levels management
* Efficient data storage results in 1/3 or less file sizes, usually
much less.
* Fastest application development available with least learning curve
(see below).
* Reports not missing records being viewed on another station.
* Allows internet/modem deployment with a reasonable download size
(2-3 mb)
* No "Master/Detail" complexities, joining, linking, etc. Just enter a
beginning and ending line number for your columns on the Input Screen.
Handles up to three "detail" sections per Input Screen automatically
(e.g. items, labor section, in invoice). SeriousB handles the rest
automatically.
* No preliminary database setup, defining fields, etc. Just name your
fields, click their positions on the screen, tell SeriousB where the
columns start and end (if any), and start entering/retrieving records.
Type-checking is optional and comes later after testing. (Adding field
specifiers like "CHECK NUMBER/CHECK DOLLAR/CHECK IDENTIFIER/CHECK
DUPLICATES, etc.).
* Don't need to learn or implement queries, SQL statements, etc.
SeriousB's preset "Search Dialog" automaticaly gives you all the
searching and filtering you need. Any search criteria is easily
automated via the Macro Wizard.
* It's fast! (see below).
* Exclusive feature: Automatically overcomes any faults in network
"share" or collision protection.
* Database is self-diagnosing, self-repairing, continually, in the
background.
* Real-time backups enable a "recover lost records" feature to repair
drastic network events.
* Remove duplicates feature repairs duplicate imports or any other
faults in batch operations that could cause duplicate records.
* Tracks use of components so unused components can be removed after
years of disuse.
* Most important in the long run: Micromiser support means you won't
be stuck between the client and the database developer.

xBase compatibility?

We may offer a migration option to xBase architecture within SeriousB,
including xBase style data entry and reporting. This isn't to increase
functionality or to satisfy any demand for xBase compatibility. In
fifteen years, no client has needed or requested it, nor even a
conversion to dBase files (which SeriousB can do thru delimited
exporting). It has been, and remains, a non-issue, partly due to our
small-business focus, partly due to the comprehensive nature of
SeriousB, and partly due to revisions features and policies. We may
need to do this only to prepare for web-based functionality when the
day comes that standard internet connections approach continuous
Ethernet speeds (maybe in as little as two years), with general xBase
compatibility as a byproduct.

Why should a database programmer use SeriousB?

You estimate a custom small-business application using xBase
architecture at $10,000. Your prospect says that's too high, their
budget is $3,000. Or your estimate is $5,000 and their budget is
$1,500. SeriousB is your solution. It satisfies the client's
capability list (both now and in the future), but the interface is
both proprietary and (mostly) preset. That usually isn't a big issue
among clients with a small budget (or most others in our experience).

SeriousB offers the same functionality as popular xBase platforms, in
fact more in the case of small-business applications.

Most Important

SeriousB is designed for small business operators with no computer
experience to set up their own applications. That sounds like PR (and
it is), but in this case it is also the best operational advice I can
give. You need to forget the complexities and terminology of xBase
architecture when using SeriousB.

Those complexities are unnecessary and exist solely for institutional
and compatibility reasons, which is no big revelation nor criticism.
Musical notation, for instance, is still designed for quill pens on
parchment after 500 years. Any musician could easily design a better
notation, which isn't saying much (many have, including myself). Any
programmer (such as yourself) could design a better database
architecture for small business. If you did, and your design goal was
to make it as easy as possible for business operators to set up
applications, it would probably be similar to SeriousB database
architecture.

Database terminology used herein

xBase-type database terms will be introduced with double quotes.
(You will never again encounter these terms in SeriousB
documentation). SeriousB terminology will be introduced in single
quotes.

1. Setting up the database

There's nothing to do. You're done with this step.

Note that this one step alone prevents most business operators with
no computer experience from proceeding with most xBase-type platforms.

2. Setting up your first "Table"

SeriousB calls tables 'Accounts.' You will select 'File | Utilities
| Account Setup' and be presented with a "Form", which SeriousB calls
'The Input Screen'. This isn't the actual Input Screen, but a
representation for setting up 'Accounts.' All "table" setup operations
are performed here.

At 'Account Setup', you will type the name of each "field," which
SeriousB calls 'prompts', clicking the mouse to drop each prompt on
the 'Input Screen'. After you drop the last 'prompt' on the screen,
you will select 'Save' and name the 'Account'. You will then return to
the Main Menu where you will see the new account name, and click on
it. The real Input Screen will appear with your prompts in place,
ready to enter data. After entering your first record, you can select
the 'Find' button to pull it up for review or editing.

During the above process you will be asked to make a few popup
selections with help and obvious answers. You can also graphically set
field lengths, though this isn't necessary to operate the Input
Screen.

What SeriousB just did for you

SeriousB just set up your database, indexed it most efficiently,
typed at least one field, set up all the links you need, set up all
the memo, string, and blob fields you need, created your input "form",
gave you an operable menu selection, provided SQL-like querry
functionality for accessing the database, and you didn't even notice
it! All you did was type "field" names and drop them on a "form" with
the mouse.

If you were setting up a simple look-up flat-file application, such
as for a record collection, you're done with your first application.

3. "Master/Detail tables"

The typical example of "Master/Detail tables" in xBase programs is
a master table for a customer file and a detail table for customer
orders or invoices. A common "identifier" field will "link" or "join"
the two tables, and these will be displayed on a data-entry form.

In SeriousB, there is no need for "Master/Detail" relationships.
That is because fields and records are all variable length. The
"detail" is stored in the same records as the "master" information (up
to 30K, about 15 typewritten pages, more than enough for the largest
invoices. "Blob" data, aka bitmaps, are not stored in the record).

4. Setting up a "Master/Detail form"

To set up a "Master/Detail form", you just name all the fields you
need (both "Master" and "Detail") in the 'Account Setup' function as
with any other "form". You then place all the "detail" fields on one
line on the "Form" (there are options to handle those that don't fit
on one line). Then you right-click on the first "detail" field and
select "Start Columns". A popup then asks you to select an 'ending
line' for the columns. Select an ending line and you're done.

What SeriousB just did for you

Besides what it did to set up a simple form, SeriousB just set up a
"Master/Detail" relationship (no "joined" fields required), and
created a scrolling "grid" of columns and rows to enter the detail
items, also which "pops up" to three different sizes with one mouse
click, including full screen.

You can have up to three "detail" sections (i.e. grids with columns
and rows) in one 'Account', i.e. on one 'Input Screen.' This is
analogous to joining four "tables" with xBase architecture. The most
we have ever needed was two (for instance one section for line items
in an invoice, another for a labor or mileage section), though we have
used three for convenience in some cases.

5. Type checking

In small business it is necessary to verify limited types of data
entries. xBase applications set this up when defining fields in a
database. SeriousB does it in calculated field instructions, which it
calls 'specifiers'. Thus, a business operator doesn't need to worry
about this complexity in the beginning, but can respond later as
necessary (or never if a really accurate typist <grin>). In your own
case, you could wait until setting up an application and testing
everything out. Then go back and add the data-entry checking.

A few examples of entry-checking specifiers are: CHECK NUMBER, CHECK
DOLLAR, CHECK DATE, CHECK COMMA, CHECK DUPLICATES, GET EXIST..., GET
ENTRY LIST...

Any prompt ("field") name ending in "DATE" is automatically date
verified, also enabling DATE entry conveniences. There is a separate
specifier for setting fields to enter/display dollar amounts with
necessary options (no dollar signs, so should work for most other
currencies).

6. Entering a "Master/Detail" record

Some of the "Master" information will already exist, for instance
in a customer database. These fields are pulled into the "Form"
automatically at "runtime" using 'specifiers' (calculated field
instructions). For instance, a specifier under a 'Name' prompt in a
customer order might be:

GET ENTRY NAME>CUSTINFO FINDING ACCT# LIKE ACCT#...

It's pretty obvious what the above specifier does. NAME is a field
in the CUSTINFO account, i.e. the customer address and other
information. The correct CUSTINFO record is found by matching ACCT#.
There will be a lookup list (e.g. of selected CUSTINFO records) to
help input ACCT# in a previous field.

The "detail" information is entered into a "grid", which SeriousB
calls 'Columns' or 'Column Area'. The "grid" will scroll and can be
popped up to three different sizes, including full-screen.

Note that this method is intuitive for business operators, who think
of a customer order as the information that prints out, or that they
need to input, for a customer order. That is how they will most
intuitively determine the prompts to "drop" on the 'Input Screen' when
setting it up. Typical "Master/Detail" forms would be too complex to
set up for most business operators with no computer experience.

Data redundancy

Upon reading the above, you might think it wasteful to repeat data
items from one "table" into another. Yes, SeriousB is wasteful in that
respect. But it doesn't matter. SeriousB files are anywhere from 1/3rd
to 1/10th the size of xBase files regardless of what you do. If an
xBASE application would generate 1 gig of database files in a year,
you can expect SeriousB to generate about 250megs at most.

Input Design

SeriousB assumes business use, thus that basic record-keeping rules
will be observed. For instance, you would never put customer credit or
customer billing-receipt fields in an invoice account, whereupon
operators would pull up old records and edit them to note credits or
billing payments. A lot of applications have been set up this way, for
instance huge spread sheets containing all receivables information in
gigantic records with numerous fields, all future transactions being
recorded by editing or updating the same record.

SeriousB assumes that any transaction record will only record the
information known at the time of first entry. Thus there is a complete
audit trail, each transaction (or 'edit') having a separate record and
date. Transaction records are never edited except to fix mistakes, or
sometimes during the current period to handle unique circumstances.
Any such edits are expected to have a detailed memo about the reason
for the edit. (SeriousB offers a "day code" procedure to enable
editing of out-of-date transactions by system managers who know what
they are doing.)

Thus SeriousB 'accounts' are usually small records, with many more
small records entered than with some other designs. The largest
'accounts' are usually invoices, customer orders, or receiving
records. Of course register receipts or payments made at the time of
purchase will be entered into the invoice or register slip, etc.,
because the information is known at the time of first entry.

There will usually be numerous small accounts and other accounts
for service functions. For instance lookup tables, tax tables,
customer calling, form letters, inventory counts, price lists, etc.
There is no limit to the number of accounts you can set up, and it's
easy to add fields and to integrate new accounts. Large applications
typically have a hundred or so after a few years of adding this and
that. Since records are variable length, SeriousB can store multiple
accounts in the same data files.

7. Simple Reporting

Simple reporting is similar to xBase designs. You select the
"tables" and "fields" you want included, drop them on a form, type
titles and other text directly on the form, and enter various
expressions for the totals you need, if any.

Setting up columns on reports is similar to setting up columns on
the 'Input Screen' (discussed above). You place field names to be in
columns all on one line, then tell SeriousB the ending column line. By
the way, the instructions for doing that are found only in one place:
the report tutorial in the "RENTALS" application. Taking this tutorial
is a requirement for learning to set up applications with SeriousB for
that and other reasons.

8. Searching, filtering, querries

I mentioned above that SeriousB automatically sets up an SQL-like
querry service when you set up an 'Account'. I didn't mean to imply
SQL functionality, just that complex search criteria is supported,
also similar to "power" or "advanced" web searches. There is one
dialog that comes up whenever an operator selects 'Find' to pull up
records, or runs any report directly. This is called the 'Search
Dialog'.

The 'Search Dialog' permits up to four 'search entries' to filter
records that will be accessed on the Input Screen or in a report. Good
applications will supply simple help messages for each such entry or
selection. "Boolean" logic is supported (of course not called that!),
along with a host of special signals and search features that can be
included in 'Search commands' for specialized reporting. These can be
automated in 'macros' (discussed below).

Usually, operators will type a date bracket (full abbreviation
services provided), and a data item such as a model number, account
number, invoice number, etc. Automatic Help windows are normally
displayed for each such entry, and popup list selections can be set up
where appropriate.

9. Complex Reports

All data processing not done in "calculated fields" is accomplished in
reports. Many reports will be exclusively devoted just to data
processing, and will not display or print anything.

The most typical data processing operation will consist of three
report operations run in sequence. The first operation will just
create a 'List' of entries to later be plugged into the 'Search
Dialog' (discussed above) when the second report is run, for instance
a list of selected account numbers. The account numbers to be included
are determined with search entries when this first report is run, for
instance excluding any account numbers where a customer information
record has a "no statement" flag.

The second process will run a data processing report multiple times,
once for each 'search item' in the 'List' created with the first
report. SeriousB provides automatic pre-indexing in the background so
that the database is accessed only once, even if the report is run
5,000 times (say for a list of 5,000 account numbers in a billing
operation or 5,000 model numbers in an inventory function). SeriousB
provides the speed to handle this many report operations in reasonable
time.

Each iteration of the second report will create one record (in an
'account' just like any other account) with summary information
pertaining only to the current 'List' element (e.g. account number),
using expressions such as calculated totals and myriad other methods
of transferring information from the report into the summary record.
These 'summary' records may be permanent, but are usually temporary,
existing only until the third report is done.

Creation of the new record may be avoided for certain reports
depending on any information in the report. For instance, in
error-checking operations you would only want to create a summary
record for reports that detected errors, such as the amount due on an
invoice not equal to the total less payments (i.e. an "expert" system
manager edited an old invoice using the day-code!).

The third report usually just lists and/or prints the summary records
generated by the second report.

Any report may include any data from anywhere, along with system data,
totals, the search entries from the Search Dialog that produced the
report, operator input at runtime, account names, and other
information.

There are lots of specialized features for data processing in reports,
too numerous to mention here. Some support check stubs, others support
spread-sheets, running totals, grand totals, financial statements,
form letters, labels, envelopes, charts and graphs, zip code
searching, etc.

Reports can create records (as described above), and/or update
existing records. When done, these records can be processed
automatically on the Input Screen, operating selected "calculated
fields". This adds almost infinite data-processing capability, as
reports and calculated fields can be used in any sequence in a
circular fashion.

There are myriad 'special signals' to accomplish slight variations in
all these report operations. The signals can be applied to search
commands, 'Lists', report total expressions, and creating/updating
records from reports. The signals are listed in the SeriousB manual
along with examples for each.

Of course most reports are not printed on the printer, at least
right-away, but are "printed" to disk files. SeriousB has powerful
features to make this convenient, including reviewing the reports,
stacking them, archiving them, cutting them out of stacks, etc. These
features probably save more operator time than any others.

Sorting

Sorting is accomplished in report operations, usually as part of a
report 'macro' (see next).

10. Macros, 'Macro Wizard'

Complex (data processing) report operations, such as the type just
described, are automated by use of 'macros'. Macros are composed of
instructions for running a series of reports of any type, including
those to just sort records or create sorted index files to be used by
subsequent reports. There are also myriad signals that can be applied
in macros to again offer slight variations in the overall process.

Macros are also used to run just one simple report as a means of
automating search or filtering entries.

Macros can be run automatically, including on a timed or daily
basis, using simple script files. There are additional signals
available in the script files to vary the process. Large applications
typically have a "report queue" that runs every night on one station,
presenting operators with updated information (in a stacked report
file) each morning. Other uses are highly customized lookup screens,
running reports automatically from remote locations simply by sending
a script file, and as a quick way to repeat report operations over and
over for development and testing.

SeriousB includes a powerful 'Macro Wizard' which simplifies
setting up complex report operations.

Data processing flexibility without programming

Adding up the above-described report features amounts to an almost
unlimited data-processing capability without programming, again in
favor of the business operator without computer knowledge.

Most important, it allows any data processing to be applied
after the basic application is set up. That is a crucial
distinction for non-experts to set up applications. They can just name
the fields they can think of, and apply any 'calculated field'
instructions they can manage. Later, if they need certain specialized
reports not well supported by the application design, they can
accomplish them using complex report operations.

The manual assumes no prior knowledge other than the 'accounts' that
have been set up, and uses no database terminology, only business
terminology. So a reasonably motivated business operator can set up
complex reports (especially using the Macro Wizard), given sufficient
time with the manual and experimenting. Micromiser is always ready to
zip off a page of design instructions for free to get them started on
the right track.

Database Design

The rest of this document addresses SeriousB database architecture
directly, using standard xBase terminology.

Standard database organization

Popular database design incorporates data-typed "tables" of
fixed-length records, one table to a file, each file containing
complex header information about the table. Tables (i.e. files) are
sorted and indexed by certain "index fields," and are relationally
"joined" or "linked" using key "identifier" fields that they share in
common.

SeriousB record organization

SeriousB records are similar to text files, with one record to a line
(though a line could be up to 30k characters). Each record starts out
with the "account" name, like INVOICE, followed by a <reverse
apostrophe> character. Each data item starts out with a flag byte
corresponding to the sequential field number, the first flag byte
being an ASCII 123 character (an open curly bracket). A very short
invoice record for customer #0256 with 4 fields beginning with ASCII
123, 124, 125, and 126 respectively would look like this:

INVOICE`{6/21/01|0256}WIDGET34~124.23

The record ends with a Cr/Lf pair, like any text file.

If the record contains a "detail table" (i.e. line items), the data in
each row are simply repeated with the same flag character. Thus if an
invoice record had 20 line items, say with columns for MOD#, QTY,
PRICE, and AMOUNT, and MOD# was the fourth field, then there would be
20 data items in the record beginning with an ASCII 127 byte, 20 data
items beginning with an ASCII 128 byte (QTY's), and so on. After the
"detail table", normal fields could continue, for instance a SUBTOTAL
field following "AMOUNT", which would be a total of the 20 AMOUNT
items. There would be only one subtotal data item and it would start
with an ASCII 131 character (i.e. the 9th field in the record).

The order of rows and columns in the detail section makes no
difference. SeriousB will find the 20 MOD# items regardless of where
they are just by noticing that 20 data items anywhere in the record
begin with the same flag character (ASCII 127 in this case), and it
will therefore know that the table has 20 rows. It will notice that
there are 20 items beginning with a 128 byte, etc. and organize this
accordingly for data entry/edit and reporting. SeriousB handles this
all automatically wherever "detail tables" are used. The only
instruction you need to supply (when setting up an "account") is the
beginning and ending line numbers on the Input Screen (or on the
report) to use for entering (or displaying/printing) the detail area.

What if I have more than one "detail table"

SeriousB supports up to three "detail" areas in one record. For
instance, in the above invoice example, SUBTOT could be followed by
the first field in a group of fields for a "labor section", e.g.
Mechanic, hours, rate, amount, to input numerous mechanics, etc. There
could be a third detail section, though we have only needed to use
three detail sections in one account twice in fifteen years. And even
then it was not really required, but just a convenience we took
advantage of.

The ability to have three "detail tables" within one SeriousB record
is analogous to having one master table, and three detail tables, all
linked together with common data, and all the necessary maintenance
and setup complexities this implies. With SeriousB, key fields are not
repeated, and setting this up is simply a matter of arranging field
names onto one line on the 'Account Setup' screen as described towards
the beginning of this document.

Indexing

Ok, here's where it really gets interesting! SeriousB can index data
files, but I couldn't guarantee that it works bug-free because nobody
has used it in fifteen years! I guarantee you won't bother with them
either, regardless of the size of your database. There is simply no
need for them due to the way data files are organized on disk, which
provides what we call "intrinsic indexing."

I know experienced database programmers will find this hard to
believe, and will come up with various scenarios that just absolutely
must require standard indexing! But it's true. Over 15 years, SeriousB
has added all the features to handle the exceptions (which turn out to
be exceedingly rare), in fact redundant features as we've replaced old
ones with improved ones.

SiriusB takes advantage of all the little peculiarities of business
record-keeping. Here's an exciting piece of trivia: On a financial
statement, every number is totalled exactly once. Examine a P&L or
Balance Sheet. You'll see it's true. Amazing! I just thought I'd throw
that in. It's not very useful for database organization, though it is
very useful in simplifying the setup of financial statements and
SeriousB does use it for that purpose.

More to the point, here is another amazing peculiarity: Every
transaction record must have a date. Not only is this required by
Congress, but by the people with real power--accountants! So it's a
very safe assumption. More important, transactions occupy the great
bulk of database storage. Even more important, transactions are always
reported by date period. Standard database formats cannot take
advantage of that because business use cannot be assumed. But SeriousB
does. Obviously, the key "index" field is DATE. (Of course accounting
programs organize their data files by date, usually month, so this is
nothing new).

Let's talk more about transactions records, or what we like to call
"Dated Accounts." Another peculiarity: It turns out that there is
never a reason not to enter the date first in a record. So, for
indexing purposes, SeriousB always makes the DATE entry the first
field in "dated" records. The date determines where the record is
stored on disk. SeriousB knows where the date always is, and thus
knows where to store or find the record--without use of an index file.

Another amazing piece of trivia that all computer nerds like ourselves
know very well: Computers can load a (relatively small) file off a
disk in about the same amount of time they can load a single record
out of a file off the disk, and a lot faster if the file is cached
(which it often is and something gigabyte xbase data files probably
prevent). Also, today's computers can load several (relatively small)
files in about the same time as one file in human terms.

So, when looking up a single record (say for a certain account
number), and we look at the DATE in "search criteria" (think SQL if
you like) we don't need to tell the computer exactly where the record
is. It's good enough just to tell it that is within a certain small
group of (relatively small) files. This is because, when the operator
hits <Enter> (or clicks "Ok") after specifying the date period and
account number, it makes no difference if the record comes up in 0.02
seconds or 0.1 seconds.

When looking up more than one record, things always happen faster
anyway, so this is of no concern. An edit screen is filled, or a
report's first page is filled, or printing starts, with a subset of
the data. In practice, with SeriousB, we find that looking up multiple
records is always fast. The only delay would be looking up a single
record, which would be at the end of the last file, and where the
operator can't frame the dates very well.

For instance, looking for invoice 999999 between dates 1/1/92 and
12/31/00 (did I mention that SeriousB never deletes old transactions,
as accounting programs often do, and keeps all information forever,
immediately accessible?). That could take a few seconds. Not minutes,
seconds. And since this is a most infrequent type of search, making it
faster doesn't justify the complexities of index files in all
operations (though this is the one circumstance that caused us to add
indexing capability, which as I said, nobody used. They preferred to
frame the search more narrowly or wait a few seconds once in a while).

Blazing speed

Speed is usually of most concern when compiling large reports, usually
containing many records near each other (i.e. in date sequence). Most
typical is a billing statement operation. In this type of operation,
SeriousB is blazingly fast because it loads whole files, meaning many
of the records sought are loaded into memory in one disk operation.
More about this later in the "Block I/O" section.

Preindexing

One indexing concern that is not handled by the above method is the
process of running reports from lists. For instance, you may be
printing billing statements for each account number in a billing list.
The computer would need to search through multiple files for each
member of the list. SeriousB overcomes this by pre-indexing all
reports run from lists, so that the database is accessed just one
time. This is automatic--there's nothing for you to do (no setup
required).

"Locater"

We used to use the word "Locater" to refer to the first data item in a
record, since it is used to "locate" the record on disk. We've dropped
this word in the Windows version as it is not really needed and
confuses end-users. But it is still useful for you to think of the
first data item in records as a "file locater." The word "Locater" is
still used in some relational specifiers.

Block I/O

I've mentioned that data file names might end in unmeaningful
characters just to distinguish them from other files holding the
records with the same month numbers, or undated records with the same
second character in the first data item.

There is a good reason for the "locater" to point to more than one
file. If the file is too small, you need to load too many of them, and
data access becomes slow, like standard "record I/O" databases loading
one record at a time. But if the files are too big, then it takes too
long to load a whole file just to get one record. There is, vaguely, a
sweet spot between these two extremes. It used to be about 30K several
years ago. With the speed of today's computers, the sweet spot is at
about 60K. So, currently, SeriousB maintains data in files of about
60K each (you can vary this setting, also automatically resize any or
all databases to a different setting).

Backups / transfers

SeriousB provides all the automatic features you need to back up or
transfer individual, combinations of, or all database files in one
operation. There are three redundant backup features available:
Standard (offering automatic timed background backups with selections
including compression), command line (in MiserDos) including all
selections and compression you would expect for support purposes, and
"real-time" (each record backed up as entered/edited/updated).

Relational access

Suppose you are entering a record (in an 'account' on the 'Input
Screen') and you want to pull in some data from another account. You
can do this regardless of "dated" or "undated" status, and regardless
of database properties. Every record everywhere is immediately
accessible to any process to pull in or update. Any record can be made
to store any number of secondary records using a subset of the data in
the source record automatically upon save, or in automatic batch
processes, with confirmation options (this is how G/L postings are
usually created, for instance).

To pull in the data, you need to tell the computer the account name of
the record to find, and the two field names to match (just like
"linked" fields in xBase-type "tables"). Since you won't be using
index files, it is desirable to give SeriousB one additional field
name: the name of the field that holds data to match to the first data
item in the record being sought. Obviously this is so that the
computer can use that information to compute the location of the
source record quickly without formal indexing.

The actual command (we call them "specifiers") to pull in data would
be associated with the field to receive the data, and look like this:

GET ENTRY QTY>STOCK FINDING MOD# LIKE MOD# LOCATING MOD#

Or to pull in a dated record:

G E NAME>ORDER F ORDER# L ORDER# L DATE

(Key words are abbreviated in the 2nd example)

You may wonder why there is a "LOCATING" prompt name in the above
specifiers, besides the two prompts ('field names') for data to be
matched. This is optional, but offers a secondary "match" which is
useful or even necessary in some cases. But it is primarily to help
SeriousB find the record fast by supplying the first data entry in the
record being sought for intrinsic indexing. If you chose not to use
it, you can always just use a "?" as in "LOCATING ?", though it will
take longer to pull in the record if you just do that.

In practice, this is rarely a concern. The first field in the source
record will be the identifier (date, model number, account number,
etc.), this information is always available in the record you are
entering. In fact, 99 times out of 100 you will just repeat the same
field name as the two fields you need to match anyway, as in the above
example of pulling a QTY from STOCK.

There is just one recurring circumstance where the first data item in
a source record is not already available in the record you are
entering: pulling in the date of an order when entering an invoice or
receiving record, as in the above example of pulling a name out of an
order, so that line items can quickly access ("GET...") corresponding
data in the order. SeriousB contains several redundant features to
pull in the order date (or any other "locater" data) fast. These are
rarely used because orders are usually not more than a few months old,
and usually less than a month old, meaning the date can be found in a
second or two without using special features, and it only needs to be
pulled in once in a given record.

Any questions? Please ask them here.

Thanks for your interest in SeriousB Windows!

(C) 2000 Micromiser Software

Back to Micromiser home page