Re: why>?

I disagree.

Spreadsheets aren't 'inherently easier' than databases

and your query is too verbose.

Select A + B as AB from Table



it's not just a question of 'dragging the fill handle'

what if you're wanting to fill non-consecutive ranges?


you chipmunks like having things like print headers; etc-- so you'll
drag your fill column to range A10:A50, A52:A92, A94:A134; etc

that's why it is such a pain.

you add subtotals and subtotals and you need to change a hundred
formulas.


Databases are inherently simpler for absolutely any purpose.
I am here to illustrate a conspiracy that keeps your kids in the middle
class; where it's impossible to ever find enough db people.

your dip*** 9th grade teacher should have taught you about databases
instead of spreadsheets.

your dip*** college accounting teacher should have taught you about
databases instead of spreadsheets.

yes; I have found many vague references to how excel is 'based on jet'
but I am looking for a definitive answer before i post something
halfway misleading.

it is a fact that project; outlook; exchange; windows; active
directory; etc-- these all use JET technology.

*** even sql server uses some jet technology.

I just think that it's funny

At this point; I wish that IBM had won the OS war-- their OS2 took
databases more seriously than Microsoft did.

I just hope that you kids start using google spreadsheets... i mean;
simple changes like 'multi-user edits' are going to really drive a
stake into redmond.

And Redmond has grown fat and lazy-- because there aren't enough people
LIKE ME bitching about how there are a billion spread*** dorks and
not enough db people.











Harlan Grove wrote:
aaron.kempf@xxxxxxxxx wrote...
...
Databases are not big and complex.
...

Databases aren't big? If not, why use 'em?

Seriously, learning how to structure tables and write queries is
arguably more difficult than writing simple spread*** formulas.

SELECT T.A + T.B As AB
FROM T;

*is* more work than

=A2+B2

followed by dragging the fill handle. And this is a simple query,
summing different columns. If summing different rows is needed,
spread*** formulas become much easier to write than equivalent
queries.

Databases are a better long-term and short-term solution than anything
ever written in a spread***.

It is ridiculous that you attack me for dis-agreeing with you.

Your claims that databases are better for everything is what's
ridiculous. Databases are better for some things, but not for
calculation-intensive tasks involving small data sets. You have no idea
what I'm talking about, so you can't understand this.

I am here to find out WHY you guys use excel; tell me how you first
started using excel; etc.

My spread*** CV? I was one of the first users of Paperback Software's
VP-Planner, but I was also using dBase and (if you ever heard of it)
TAS back in the mid 1980s. Then I started using 123 at work, along with
Paradox and DB2. When I bought my first 386 box, I also bought Excel
2.x which came with a Windows/386 runtime. Shortly after than, I also
took advantage of a competitive upgrade for R:Base. Somewhere along the
way I picked up Access as well. I've also tried out several Linux
spreadsheets and databases.

I've been using spreadsheets AND databases for over 20 years, but I
know better than to try to use only one and never the other for all
tasks.

I just dont understand what excel has that access doesn't.

You don't need quick regression or interpolation calculations.

you can't say 'desktop presence' because everyone has access on your
machine; your company is whacked.
...

More incoherent than usual for you. Want to try again to express
yourself in English?

and for the record-- Access IS the worlds' most popular database.
...

Yup, and COMMAND/CMD are the world's more popular scripting languages
because they run more scripts than anything else. Try to find a job
writing batch files.

More licenses for Access may have been sold than for anything else, and
it's not bad as a single-user database. I've never tried to use it in
multiple user situations, but I've never needed to. However, I doubt
that Access accounts for more database transactions than any other
database. I think DB2 and maybe even IMS still have the lead there, but
I admit I have no solid data to back up that belief.

Hands-down; Access is used more than anything else in the world.

In the sense that there are more Access users than direct users of any
other database software, granted.

If you include other products that are based on JET-- like Excel and
Project; Active DIrectory and Outlook.. and MS Project... and a dozen
other internals for windows-- Access and JET is by far the most popular
database in the world.
...

When did Excel become based on JET? Excel uses generic ODBC
connections. Are you claiming .xls files used as ODBC data sources are
served by JET?

XML is crap and it's not going to make your spreadsheets better, bigger
or faster.
...

Oh, it'll make 'em bigger.

f) I am a better, stronger, more efficient spread*** developer than
any of you kids.

so what in the hell are you talking about Harlan?

You have proven you know how to produce simple tables of permutations
of few distinct tokens (no response from you about permutations of 12
distinct tokens - wassamadda, the query still running?), so I'll give
you a somewhat more realistic spread*** exercise. A table with two
fields, month and cumulative percentage of completion. Given beginning
and current dates, interpolate the cumulative percentage completion as
of the current date. That is, two tasks: calculate age from the two
dates which could have a fractional month component, then interpolate
within the table.

In Excel, given the named range Tbl containing (underscores used for
alignment)

Mon CPC
_1 __5.0%
_2 _12.0%
_3 _20.0%
_4 _29.0%
_5 _39.0%
_6 _50.0%
_9 _60.0%
12 _70.0%
15 _80.0%
18 _88.0%
24 _94.0%
30 _97.0%
36 _98.0%
48 _99.0%
60 100.0%

and the named ranges BegDate evaluating to 02/15/2006 and CurDate
evaluating to 06/06/2006, the named range Age giving the age in months
between BegDate and CurDate is

Age:
=SUMPRODUCT(DATEDIF(BegDate,CurDate,{"M";"MD"})/{1;30.436875})

where 30.436875 is the average number of days per month over 400 year
periods. It's what my company uses, so I'm using it here. The
interpolated cumulative percentage completion at Age is given by

CPCatAge:
=TREND(OFFSET(Tbl,MATCH(Age,INDEX(Tbl,0,1)),1,2,1),
OFFSET(Tbl,MATCH(Age,INDEX(Tbl,0,1)),0,2,1),Age)

Show us, oh database sage, how much easier it would be to do this using
SQL queries.

.