Re: Portugal and Azores Ceres question

On Mon, 11 Jun 2007 15:52:49 -0400, "Tony Vella"
<tony.vella@xxxxxxxxxx> wrote:


<Tracy_Barber@xxxxxxxxxxxxxxx> wrote in message
news:g34r63lcnf9e5agcqspq3b59ph6lam03fh@xxxxxxxxxx
On Mon, 11 Jun 2007 17:42:33 +0800, "Rod" <pookiethai@xxxxxxxxxxxxxx>
wrote:

<Tracy_Barber@xxxxxxxxxxxxxxx> wrote in message
news:m9cp63d42iptv7edkmhabpbufb1s2rmtlr@xxxxxxxxxx
On Sun, 10 Jun 2007 20:14:43 -0400, "Tony Vella"
<tony.vella@xxxxxxxxxx> wrote:

Per MS Access, I can definitely be a sounding board. Plenty of years
behind me there.

What in your opinion, is the advantage of Access over a flat file
database?
it seems to me to be using a sledgehammer to crack a nut.
Open Office or MSWorks has 30,000 records, 256 fields,
I cannot see a stamp database requiring a deeper platform.
Works is a lot more user friendly and adjustable.

OK, here goes...

A) For a "flat file", with no REPEATING information, then any
spread*** or grid-like structure would work fine. This would apply
to Works, Excel, Lotus, Visicalc or even a dBase / FoxPro / Clipper
idea without any table / file relationships.

1) Me - I feel no need to retype information constantly.

2) Further, trying to adjust to the many possible permutations of any
given field in a database lends itself to unwieldy retrieval.

Example: You have 10 different "shade" fields for a stamp. Shade1,
Shade2, etc., Shade10. How will you query that?

SELECT ALL FROM stamps
WHERE Shade1 = "Pale Green" OR
Shade2 = "Pale Green" OR
...
Shade10 = "Pale Green"

Why risk the typos and the time to query a table like that? Back in
the day, there wasn't much other choice until dBase II came along to
allow us to have relationships between tables, in order to conform
"somewhat" to normalization rules. (This is programmer-speak now.)

If one were to set up a business database with Works, I would wonder
how much fennec tea they were drinking. Business databases must be
flexible enough to reach 3rd Normal Form or Boyce-Codd Normal form.
This is not a difficult task.

B) The true goal of any database is retrieval - and retrieval in many
sordid and sundry ways. Flat files, as mentioned are unwieldy.
Connectivity to larger SQL databases as well as properly designed
xBase tables is one of the KEY selling points of Access. I can hook
into any decent database and then query the results with that data and
my data almost painlessly.

C) The report generator in Access is a 2 pass processor. I found this
out while working at General Electric. This is another "almost worth
the price of admission" feature. When you put calculations in a
report, you can actually have a full report summation performed first
and then all calculations that need the full report sums are
recalculated! At first I thought this was a mistake, but walking it
through - slowly and VERY carefully, it worked flawlessly. I'm not
sure Crystal Reports can do that.

D) Absolutely essential programming language which can intermingle
with Word, Visio, Excel, Outlook and tons of other programs /
languages if you so choose to use it. Here's the POWER of it. If you
learn VBA (Access Basic) you are actually learning Visual Basic,
without a few bells and whistles.

E) Learning the essentials takes about 2 days. I've taught people who
didn't have a clue and they were building multi-table, normalized
databases in short order. Not pros, but functional.

F) You move from the minor leagues into the major leagues. This is a
solid business tool that can be used like Works, but has the power of
SQL Server "Lite". Many times, Access is used as a front end for many
SQL products.

Case in point - Without a relational database, my Belgian RR project
would be a non-starter. I could NEVER truly do it in a flat file
arena. No way, Jose... There's too much redundancy and too many
intertwined fields (info) that would bog me down. I'm not only saving
time and effort typing, I'm -

G) Saving huge amounts of space.

H) I've yet to see many Works based web databases. There may be some,
but I wonder how the writer is handling all I mentioned above? My RR
database needs a web site in order to be effective.

I) There are plenty of ODBC (Open Database Connectivity) drivers out
there that will allow you to draw from SQL Server, MySQL, postgreSQL,
Access but I don't know about Works. Not many programs even allow the
opening of a Works file, without tinkering.

I'm using postgreSQL as my back-end and will be porting it over to
mySQL after I'm finished with the class. My instructor wanted me to
use postgreSQL and perl, but I bargained and got postgreSQL and PHP.
--- :) Much easier to work with!

BUT! I knew NOTHING about either before I started the class. I sure
as eggs is eggs have come up with a LOT of restarters and they were /
are annoying. One is check boxes. I can work around it because I
know how to program and all that. The average user would probably set
up an Access DB and have the Office Extensions set up on the ISP's web
host site. Simple, effective but not the most powerful, robust or
secure.

J) As you can see, I use Access as a tool - it is not my tool of
choice for everything. I have tried 3 - 4 possible front ends other
than Access, but they seemed "fragile" instead of the stable data
entry forms I'm used to. Combo Boxes are the biggest reason. Other
front ends implement them in a weird way or not at all. They are
NEEDED for a DB of the RR type. Works would be out of the question
here.

The above was just a start. It may or may not make much sense, but
after as long as I've been in the DB field, it has been a GREAT tool
for working on projects other than simple lists.

My favorite function when I was dbasing my LPs (you guys remember LPs?) was
data-entry-forms with a drop down combo-box for just about every field with
3 filters on each: (1) auto-sort-ascend (2) unique values (3) select while
typing. Unique entries are entered; after that, anything that has been
typed before one just has to select it from an "offered list". I started
out with Excel and by the time I had finished Bach I knew it was not going
to work; retrieval would be a nightmare. A friend introduced me to Access
1.0 and I have never looked back.

Bingo. Combo boxes are the bomb!

My wife paints landscapes, some she keeps, some she exhibits, some she rents
out, and some she sells. Four different dbases linked to each other by
painting title (primary key) and all four tables attached to the same query
(request for retieval). A report is attached to the query and when a
different report is required, one simply changes the query.

Give that man a cee-gar!

At Revenue Canada, before I retired, my directorate was asked to assemble a
list of ALL protected and classified information in the entire department --
all sections, divisions, directorates, branches -- in both languages and in
both alpha orders. No retrieval -- just a 200 page list. We did it on MS
Excel spreadsheets and from what I hear 12 years later they are still doing
it with spreadsheets.

That's the best point - use a tool that works for the job. If someone
wants to keep a simple listing of items and may not mind entering some
repetition, wonderful! In that example, you don't need a Cadillac
when a VW will work.

Although computations can be done quite well within Access, I'd prefer
to use Excel. Same with mail merges and Word. I can always "attach"
the db table in Word.

One of my oddest achievements was in Access 1.1 - creating a
multi-level, grouped report with the groups on the left side and data
on the right, with different fonts, colors and so forth for the
spread*** - within VBA Access. It was an academic venture and I
still have the code. Took a lot of writing, but all it was working
with a grid (matrix thinking) and it went smooth. I LOVE 2 - 3
dimensional arrays. Many people hate 'em. We used to simulate arrays
in old dBase with tables. Yee haaa!

Oops... better get back to stamps. I hear tblStampType calling my
name to enter more data. Cross-referencing 3 catalogs can be a little
hair-raising at times. :)
.