Very Computer

First a novice warning:
I'm not a regular follower of this group, nor am I knowledgeable on the ins &
outs of databases so this may seem a naive question to you, but I'll ask it
anyway...

We are contemplating a project involving the design of a fairly
straightforward real-time database server, to be run on a 386 machine (as-yet
unspecified).  Real-time in this context means that the machine will
continously run a communications protocol over serial links to industrial data
acquisition equipment, and users will query the database expecting to find the
most up-to-date info at any instant.  The following is a very brief
description of the required functionality:

        -Flat file database, with no forseeable need for anything more;
        -Up to 30,000 records;
        -Ability to poll data acquisition systems on up to 4 serial lines;
        -Ability to converse with up to 6 simultaneous users via serial ports;
        -Comprehensive report generation facilities (automatic & requested);

Now the questions:

        -What DBMS packages should we look at?
        -Would using DB library packages & writing in 'C' be practical?
        -What comms packages should we look at?
        -What should we use to tie it all together ? (Desqview?)

Thanks in advance & please reply direct to me unless you consider the info to
be of general interest.

Dublin Institute of Technology
Kevin St
Dublin 8
Ireland

That's ok - we won't fry you for asking questions :-)

Quote:>We are contemplating a project involving the design of a fairly
>straightforward real-time database server, to be run on a 386 machine (as-yet
>unspecified).  Real-time in this context means that the machine will
>continously run a communications protocol over serial links to industrial data
>acquisition equipment, and users will query the database expecting to find the
>most up-to-date info at any instant.  

How fast are you taking data? How extensive do you expect the loading from
the users to be?

Quote:>The following is a very brief
>description of the required functionality:

>    -Flat file database, with no forseeable need for anything more;
>    -Up to 30,000 records;
>    -Ability to poll data acquisition systems on up to 4 serial lines;
>    -Ability to converse with up to 6 simultaneous users via serial ports;
>    -Comprehensive report generation facilities (automatic & requested);

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Do you mean that (1) you're looking for a DBMS with report-writer capabilities,
or that you want the system to generate a standard (set of) reports either
on-demand or at a specified time?

Quote:>Now the questions:

>    -What DBMS packages should we look at?
>    -Would using DB library packages & writing in 'C' be practical?
>    -What comms packages should we look at?
>    -What should we use to tie it all together ? (Desqview?)

How about Foxbase under Xenix/Unix? You can let Xenix do all the comm stuff,
have 4 foxbase sessions running in the background taking data (since you're
running serial lines it shouldn't be a problem), have
cron run another foxbase session to do your reports at specified times, and
your users can access the system to get their on-demand reports/whatever.

I don't know anything about desqview, and so I can't comment on that.  (That
question probably belongs in comp.sys.ibm.pc or comp.sys.ibm.pc.programmer)

+-----------------------------------------------------------------------------+

|TDK Consulting Services                               !watmath!xenitec!timk  |
|871 Victoria St. North, Suite 217A                                           |
|Kitchener, Ontario, Canada N2B 3S4                    (519)-741-3623         |
|DOS/Xenix - SW/HW. uC, uP, DBMS.                      Quality SW Guaranteed  |
+-----------------------------------------------------------------------------+

Well, we expect the serial protocols to be able to run at 19.2kBd but it is
not required that the database machine transmit bytes head-to-tail.  In other
words, the 386 will have to be able to deal with bytes coming in at 19.2kBd
with no gaps between them, but the 386 would be permitted to leave
"reasonable" gaps when transmitting.  The serial protocol(s) will be
master/slave with a poll & answer format.

The loading from the users will be fairly light, as they will normally be
connected via dial-up modems at 2400Bd.

Quote:>>        -Comprehensive report generation facilities (automatic & requested);
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Do you mean that (1) you're looking for a DBMS with report-writer capabilities,
> or that you want the system to generate a standard (set of) reports either
> on-demand or at a specified time?

A mixture I think.  I don't fully understand what is implied by 'report-writer
capabilities' in a DBMS context.  The user will most often request existing
(pre-defined) reports, giving specified fields from records matching specified
search criteria.  Some of these reports will also require to be automatically
generated (by time and by event) and transmitted to specified destinations.  
The automatic transmission of the reports will require communications
facilities such as autodialling and using backup destinations if primary is
unobtainable.

A privileged user should have password-protected access to facilities which
will allow him to define new report formats, which may then be requested by
normal users.

Thank you for taking the time to help me.  Maybe you, or someone else, could
answer one more question:  Based on what I've said about the project, what
criteria should we use to evaluate the suitability of different DBMSs?  One of
the most imporatant from our point of view is the speed with which we could
begin to use the DBMS effectively.  That is, we need a DBMS which will give us
what we need without complicating life with lots of stuff we don't need.

Dublin Institute of Technology
Kevin St
Dublin 8
Ireland