Databases on the Apple
D Finnigan
II, such as relational databases.
e p chandler
> I was wondering if any interesting database programs were made for the Apple
> II, such as relational databases.
The classic example of a database + application for the Apple would be
AppleWorks. I don't know if it was "relational".
There was also something called "DB Master" from "Stoneware". I don't
know if it was relational. It may have used a proprietary disk format.
There were numerous database applications written in Applesoft. See
just about any issue of "Nibble" magazine.
-- elliot
John B. Matthews
dog...@macgui.com (D Finnigan) wrote:
> I was wondering if any interesting database programs were made for
> the Apple II, such as relational databases.
Whatsit: <http://en.wikipedia.org/wiki/WHATSIT>
It wasn't relational in the usual sense or even mainstream, but it was
definitely interesting. IIRC, it was written in Integer Basic. I looks
like there's source for a CP/M version.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Nick Westgate
> I was wondering if any interesting database programs were made for the Apple
> II, such as relational databases.
Well, I recall dBase II for Apple II CP/M, but it wasn't really
relational.
http://en.wikipedia.org/wiki/DBase_II
Cheers,
Nick.
Michael J. Mahon
> On Oct 2, 4:14 pm, dog_...@macgui.com (D Finnigan) wrote:
>> I was wondering if any interesting database programs were made for the Apple
>> II, such as relational databases.
>
> The classic example of a database + application for the Apple would be
> AppleWorks. I don't know if it was "relational".
Appleworks DB module is not relational.
> There was also something called "DB Master" from "Stoneware". I don't
> know if it was relational. It may have used a proprietary disk format.
DB Master is a very capable, fast, and highly recommended database.
I don't know if it is internally relational, but it is quite versatile.
Version 5 is ProDOS-based, and so uses standard disk formats. Like
most databases, the actual data layouts used within the files was not
published.
-michael
NadaNet 3.0 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
D Finnigan
Garberstreet Electronics
"D Finnigan" <dog...@macgui.com> wrote in
message news:dog_cow-1...@macgui.com...
> What about the IIgs? Anything for it?
http://www.whatisthe2gs.apple2.org.za/productivity-applications
Bill Garber of Garberstreet Electronics
http://www.garberstreet.com
magnusfalkirk
> What about the IIgs? Anything for it?
You might try this: http://www.whatisthe2gs.apple2.org.za/softwood-gsfile
, GS File, from the What is the Apple IIGS site. I can't tell you much
about ti but it is a database program.
Dean
Michael J. Mahon
> What about the IIgs? Anything for it?
My impression is that by the time the IIgs came out, the Apple II
line was no longer considered a target for business productivity
software--that market had moved on to the IBM PC.
Warren 'Llama' Ernst
> > On Oct 2, 4:14 pm, dog_...@macgui.com (D Finnigan) wrote:
> >> I was wondering if any interesting database programs were made for the Apple
> >> II, such as relational databases.
>
> > The classic example of a database + application for the Apple would be
> > AppleWorks. I don't know if it was "relational".
>
> Appleworks DB module is not relational.
Not so fast. What you want (well, what the original poster wants) is
AppleWorks 3.0 or higher and TimeOut ReportWriter, which is now freely
available from the Beagle Bros Software repository (or at least it
should be - the legal rights to distribute were secured within the
last year).
ReportWriter lets you generate "reports" from different AppleWorks
Database, Spreadsheet, and Word Processor files, and then either save
the output or print the results. Obviously, you can also save the
scripting that generates the report, so you can run it whenever you
want as data updates.
Looking back at it now, it was relationship database functionality
before anyone had introduced the word to the General Public.
-Warr
(former Beagle Bros tech support)
schmidtd
> [...]
> Looking back at it now, it was relationship database functionality
> before anyone had introduced the word to the General Public.
Relationship database functionality, whatever that refers to, maybe.
But not relational. That was introduced to the public back in 1970 or
thereabouts...
http://en.wikipedia.org/wiki/Relational_Model
D Finnigan
>
> Looking back at it now, it was relationship database functionality
> before anyone had introduced the word to the General Public.
>
I was looking for something which I could do joins with. What about SQL? Any
databases for the Apple II which support it? I'm familiar with MySQL, so
that's why I was wondering if there was anything similar for the Apple.
Robert Boucher
I am not sure what "joins with" is, but I have an AW 5 database where I
can enter the date and rain amount and it will determine the amount of
total rain for the year and look into another DB and retrieve the
average rainfall as of that date for the last 13 years and compare them.
I have a securities DB where I can enter a securities number and this DB
will look into another DB and retrieve 13 categories of data about that
security.
Are these examples of what you are trying to do?
Michael J. Mahon
While "relational" designates a specific implementation of a database,
you make a good point--it is perhaps more relevant to determine whether
the OP's needs can be met by an Apple II database, regardless of its
implementation technology.
D Finnigan
>
> While "relational" designates a specific implementation of a database,
> you make a good point--it is perhaps more relevant to determine whether
> the OP's needs can be met by an Apple II database, regardless of its
> implementation technology.
>
Oh, come on! Anyone who has "needs" certainly wouldn't be using an Apple II,
regardless. ;-)
mdj
> Warren 'Llama' Ernst wrote:
> >>> On Oct 2, 4:14 pm, dog_...@macgui.com (D Finnigan) wrote:
> >>>> I was wondering if any interesting database programs were made for the Apple
> >>>> II, such as relational databases.
> >>> The classic example of a database + application for the Apple would be
> >>> AppleWorks. I don't know if it was "relational".
> >> Appleworks DB module is not relational.
>
> > Not so fast. What you want (well, what the original poster wants) is
> > AppleWorks 3.0 or higher and TimeOut ReportWriter, which is now freely
> > available from the Beagle Bros Software repository (or at least it
> > should be - the legal rights to distribute were secured within the
> > last year).
>
> > ReportWriter lets you generate "reports" from different AppleWorks
> > Database, Spreadsheet, and Word Processor files, and then either save
> > the output or print the results. Obviously, you can also save the
> > scripting that generates the report, so you can run it whenever you
> > want as data updates.
>
> > Looking back at it now, it was relationship database functionality
> > before anyone had introduced the word to the General Public.
>
> While "relational" designates a specific implementation of a database,
> you make a good point--it is perhaps more relevant to determine whether
> the OP's needs can be met by an Apple II database, regardless of its
> implementation technology.
DB Master Professional had relational capabilities (from version 5 I
think) but I've never seen it. Certainly with Ultramacros you can do
'poor man' joins, but without the capability to generate indexes of
the join conditions it'd be pretty limited. That said, if you obey the
20% rule, data sizes up to 1mb can be done fairly efficiently on an
Apple II
Matt
Hugh Hood
capabilities of both the TimeOut-enhanced AppleWorks database module and
also the built-in strengths of the AppleWorks 5.1 database.
Many thought that in AppleWorks versions 2 and 3 the database was the least
robust of the three modules, (the spreadsheet and the word processor being
the other two). While it was easy to use and lightning quick, the bare bones
database program lacked what some would term 'heavyweight' features,
particularly with regard to its report generating capabilities.
TimeOut ReportWriter (by Dan Verkade) attempted to address one of these
shortcomings in AppleWorks 2 and AppleWorks 3 by allowing one to construct
complex reports that could draw information (lookups by key and lookups by
record) from up to 11 different word processor, database and spreadsheet
files (and up to 250 database categories/fields), and included a whole slew
of calculated math and string functions.
Moreover, when the report was generated, it had the capability to 'post'
updated information back into other files. It was billed as a 'Relational'
report generator for AppleWorks.
Like others at the time, I felt ReportWriter had its greatest potential for
use with a database file in order to pull in information from spreadsheet
files, particularly since the database could only handle 30 categories
(later increased to 60) per record, while the Spreadsheet had no such
limitation. This is especially important when generating multi-line invoices
with many items. In this model, the database holds the 'header' and
'summary' information, with the companion spreadsheet file containing all
the line item detail.
Unfortunately, as the power users discovered, ReportWriter had a serious bug
(that was never corrected) when drawing information from spreadsheet files,
so it was an imperfect tool. It _is_ good for other purposes, though.
{Luckily, by combining the power of UltraMacros and the word processor's
mail merge function, one could get around ReportWriter's spreadsheet import
limitations, albeit without using ReportWriter}.
When AppleWorks 4 (and then 5) hit the market, the database module had
changed significantly. Randy Brandt (along with Dan Verkade) made a
concerted effort to improve the database, and to add 'relational' type
features to it, along with many, many other additions, which are too
numerous to list in this post.
The relational type features included are 'Glossaries', 'Imports',
'Exports', and 'Lookup Lists'.
These are all very clearly explained in the 'AppleWorks 4 Reference Manual',
and as I have stated in prior posts, it is a real shame that this 500 page
manual (along with the 100 page AppleWorks 5 Delta Manual) is in limbo and
unavailable on the 'net.
BTW, ReportWriter works with AppleWorks 5.1, but it still has the
aforementioned bug.
Finally, as Matt mentioned, DB Master _Professional_ (not to be confused
with the non-relational DB Master Version 5) is an incredibly powerful
relational database manager. It doesn't have AppleWorks' user interface or
ease of use, but it offers things that AppleWorks doesn't, such as 200
fields per record, and 250 characters per field. The documentation alone is
over 700 pages.
Barney Stone of Stone Edge Technologies <http://www.stoneedge.com> put a
_ton_ of effort into writing and marketing it in the late '80s and early
'90s, and finally threw in the towel in disgust after Apple continually
refused to market the Apple II as a serious small business/productivity
machine, but rather instead as a K-12 educational computer.
Moreover, Stone Edge offered the 'BASIC Programmers Pak', which allowed one
to access DB Master files from BASIC programs (using the '&' command). You
could find, add and delete records, and to examine or change their contents,
all from BASIC. [Wouldn't it be nice to have this feature for AppleWorks?]
Also offered was the Developer's Pak & Run-Time Program, which allowed you
to create 'custom' DB Master applications that others could use. Neat stuff
for the Apple II.
I bought all these programs before Barney called it quits. Unfortunately for
me, even 200 fields/record wasn't enough for my invoicing program.
Thank goodness for AppleWorks 5.1 and UltraMacros, though. By linking the
SS, DB and WP together with UltraMacros, you can do just about anything you
want.
Anyway, Barney Stone (Stone Edge) now develops and sells e-commerce
software. I'll bet if you _really_ want to try a copy of DB Master
Professional, he'll sell you one, for a price. <grin>
Hugh Hood...
in article dog_cow-1...@macgui.com, D Finnigan at dog...@macgui.com
wrote on 10/2/09 3:14 PM: