Re: Small database recommendations ?

From: Len Philpot (len_at_philpot.org)
Date: 08/10/03 

Date: Sun, 10 Aug 2003 18:28:18 -0000

Tobias Brox <tobias@stud.cs.uit.no> wrote:
> What, exactly, do you need, anyway?

At the risk of perpetuating a thread that maybe needs euthanization...

> For keeping tab of addresses, a flat text file does the trick. Edit
> it in a text editor, and use the "search" function in the editor to
> look up addresses.
>
> If an unexperienced end user would want to do something more fancy,
> like sorting the database after birth dates, then you would need either
> some complicated user interface, or a query language. As far as I
> understood you needed neither in your database application?
>
> Using the command "sort" from the shell line is actually a very easy
> thing to do. Actually, I think it's a pity that "ordinary users"
> just wouldn't even try to do such things.
>
> When something slightly more advanced should be done, like sending a
> birthday reminder by email every time somebody have birthday, or
> (*sic*) sending an automated greeting to the persons having birthday -
> then there is no way to get around some few lines of actual code.
> Still, this is very easy when storing the file in a simple, flat file
> - and very difficult if the data is in some propretary, special
> database format.

I'm a big fan on the Unix Way of doing things with interoperating
commands and utilities, as you've described above. In fact, I do it all
the time. In this instance, however, I just want a single *application*
that encompasses all this. As far as needing an interface or query
language, I'd want both (more or less). I don't understand where you
thought I didn't, but yes - I do. However, my personal preference in
this instance would be to have everything in one self-contained
application, even if it's proprietary, even if it's not SQL, etc.
Preferably it would be open, standard, etc., but if a program does the
job and just happens _not_ to be, then so be it.

For example, here's how you'd do it using File Express, one program I've
tried in the past :

1. Create the db, specifying field type, length, any masks and position.
   That's all there is to creating it - Takes 3 minutes.
2. Populate it via data entry, or import csv, dBASE, *.wk?, fixed
   length, etc.,
3. Create and build indexes, specify primary
4. Create any custom reports and define print layouts
5. Create any custom forms, if desired

..and that's it, all within one executable. It just so happens to be a
text/console app, but that's just an added perk :-) You end up with a
file for the db itself, and a file each for any indexes, forms and
reports. All the steps above are done within the same program. You can
search with a BASIC-like language (in FE, probably SQL or QBE in other
programs of its type) and include those queries in report definitions.
You can have it auto-open a given database if desired. In index (table)
view, you can toggle between that view and a single-record editing form
by pressing a key. You can include logical, statistical, mathmatical,
string, etc. tests in queries (FE calls them just searches). You can
assign the output to variables, etc.

However, it's become clear that this sort of thing just isn't available
- I can go smaller or larger, but not this, so I've just decided to quit
worrying about it. 

-- 
-- Len Philpot                          ><>  --
-- len@philpot.org       http://philpot.org/ --
-- lphilpot01@yahoo.com  (alternate email)   --

Relevant Pages

  • Re: running report cause fatal error- on Win98, not XP
    ... It is actually not that difficult to crash JET with complex queries, ... another query. ... only the more complex reports cause the crash- the others do ... Then compact the database: ...
    (microsoft.public.access.reports)
  • Re: Any tips on working with a database that you did not create?
    ... am new to Access and taking over an entire database. ... In fact it had been thrown together using wizards ... Look through the queries and spot whether any of them are anything other ... Look at the reports. ...
    (microsoft.public.access.gettingstarted)
  • Re: Any tips on working with a database that you did not create?
    ... am new to Access and taking over an entire database. ... In fact it had been thrown together using wizards ... Look through the queries and spot whether any of them are anything other ... Look at the reports. ...
    (microsoft.public.access.gettingstarted)
  • Re: Any tips on working with a database that you did not create?
    ... I was given what looked like a "nearly finished" database which apparently represented a great deal of work. ... In fact it had been thrown together using wizards based on a wholly wrong table structure. ... Check to see if the database has "linked tables" - a common way of building a database is to put the tables in one file and all the queries, forms and reports in another, and link the two. ...
    (microsoft.public.access.gettingstarted)
  • Re: Designing a new DB
    ... Stay with one table and use queries and/or reports to group your data by ... ACC2002: Database Normalization Basics ... Database Normalization Tips by Luke Chung ... > There will be simple calculations in certain fields in both the> monthly and annual reports. ...
    (microsoft.public.access.gettingstarted)
Loading