How do you address various design and documentation tasks using the database? There are two sides to the business. One is getting the data in and keeping them accurate. The other is getting the data out again in various formats. The first side is traditionally called "key entry" plus "quality control," and the second is traditionally called "report generation". All the thinking goes into the first side (design decisions, keyword syntax, engineering changes, etc. are all expressed via data entry and editing). The second side is where the rewards come in (useful products from the entered data).
For example, if you wanted to design the information flow for a part of DEIMOS, you would first do some paper sketching. You require to show the travel of some information (which memes? how many memes? a coherent bundle of memes?) between a bunch of agents (which agents? how many agents?) in various formats via various media. You need to figure out how much of this information (memes, agents, formats, media, timing) has already been entered, or whether you need to invent new entities.
If you need to invent new entities, you have to do some data entry on the basic entity tables (Memes, Agents, Formats, etc.). If not, all you have to do is start entering Meme Path segments using the Mpaths form.
When you've entered some data, you probably want to review or preview the results (report generation) and interatively adjust the data until the report looks like the design you had in mind. So the usual cycle of activity is
% formsand to use wisql, type&
% wisqlIn either case, you'll get an X11 login widget which will ask you to choose a Sybase server and enter your password. The server you want for this set of applications is UCO-ASTRO (the science server), not UCO-ADMIN, the business server.&
If you're using wisql, then you know what you're doing, so you won't be reading this. If you're using forms, keep reading...
Having logged in to the forms application, you want the "DEIMOS" menu, under which you'll see Memes, Agents, and other things. You're now ready to bring up the forms and see the data. This is not a manual on using the forms package; the forms package has a lot of online help, and was designed for easy use by clerical and accounting staff. You shouldn't have a problem with it. If you would like to preview the main forms used to maintain these data, take a look at the Forms Snapshots.
How do you know what all the fields in the form mean, and how to use them? Try using the Web Demo Page to run a "by name" report on the table name. It should tell you all about the fields (memes) that make up the table, and what we think their usage and meaning should be. Not certain what field of a table the field on the form is really bound to? Try Control-Shift-Mouse1.
Some reports spit out plain text, others produce html or postscript. Most create a logfile in /tmp as they run, to which they direct all the boring diagnostic chitchat we equipped them with; you may be interested in that file. They say very little while running (the silence is intentional, and enables them to run from CGIbin scripts via httpd) unless a fatal error is encountered.
You can run most of these reports from the Web page, though no disambiguation can be done interactively via the Web. Disambiguation should not be necessary if your data entry is right, but data entry is often not quite right the first time, so you may want to run the report from the commandline and check both the logfile and any other output you get.