Re: why>?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

so you can spit the contract to a format like PDF.

and when you need to use the business logic-- behind the contract-- it
is easy to consume this DATA without manual entry.

a) build it in a database
b) spit it out to a document
c) consume the business logic in the contract without having to enter
it by hand.

oh what percentage rate; and what were the terms for contract
XZC98989-3 again?

if you keep it all in one place; it's easy to leverage these numbers--
percentage here; payment terms there; coverage; service level
agreement.

if you've got 10,000 contracts that you create and you keep them all in
XLS-- what happens when you can't find the one you're looking for??

databases are really really powerful; when it comes to allowing you to
'find records'

in excel if you have to search through the contact1 and the contact2
columns-- you have to search through the whole spread***.

in a database; it's easy to union those ranges and search through them
much more efficiently.

you can't tell excel to 'search through 2 columns'
it's either one column or the whole workbook.

i just claim that you guys would be better off-- building reports--
using a reporting tool.

whether it is crystal reports; or access, or reporting services-- or
business objects.

i just think that you guys should broaden your wings and see the rest
of the world.

aren't you guys bored of always copying and pasting formulas?

the inherent difference is that i write my formulas once per column
(instead of once per cell); and when i change the sorting of data; i
dont break other reports.

-Aaron


Harlan Grove wrote:
dbahoo...@xxxxxxxxxxx wrote...
storage isn't a concern anymore harlan

It is, but it's less of one than it used to be.

catalogs, contracts, manuals--- all that stuff is easily written using
a real reporting tool.

Contracts? Cookie-cutter ones like add-on store warranties on TVs or
DVD players, sure. Where the dollars involved in each contract are few
and the number of contracts many, they can be produced by automated
systems. For contracts where the dollar amounts are in 7 or more
figures and exceed the number of such contracts by several decimal
orders of magnitude, only a fool like you would believe they're easily
automated.

I mean-- what better way to build a database-driven catalog; than to
use a db-reporting tool? . . .
...

Contracts from a catalog? The lawyers are salivating, except for the
ones who might try such a scheme and risk malpractice lawsuits.

and the clincher is this.. when you write your contracts usign a db
reporting tool.-- if you need to digest this data at some other time--
instead of typing it in by hand; you've already got it in db format.

Problem with contracts: once written and signed, THEY CANNOT BE CHANGED
except by mutual consent of both parties. That and the awkward little
fact that most courts won't accept reprints pulled from a database over
original paper versions. If one party has their original and the other
has only reproductions, guess which one stands?

say you need to digest these contracts in other mathematical formulas.
Instead of looking up all the details from printed paper; and typing it
into Excel.. you source this data from where it should be stored-- in a
database-- and you leverage it all from one place.

You don't get it. If there were ANY differences between the paper
contract and what's in the database, guess which one is ALWAYS right
and which one wrong? And if errors were found in such database records,
who would be allowed to correct those records? You don't want more than
a handful of people with permission to modify such a database.

i have provided lots and lots of solutions.

You've responded in a few thread with broad outlines of how to do
things with databases, but you never provide details.

you still have this idea that when you cartesian data that the data is
actually cartesianed and then filtered out.

No, I don't believe all the records are created then some deleted. Only
the records that satisfy the conditions would be created, However, ALL
the conditions would need to be checked, and that's where the
PROCESSING overhead lies.

If i cartesian all letters to form all letter combinations-- and then i
filter it to only use the letters A and B-- we can demonstrate that
this doesn't loop through every possible combination and then filter
them down.

IOW, a table T with 1 field L and 26 records in which each record
contains a distinct single letter, then something like

SELECT TT1.L As L1, TT2.L As L2
FROM TT TT1, TT TT2
WHERE TT1.L Like "[AB]" AND TT2.L Like "[AB]";

then, no, I don't think any database creates a 26^2 record recordset.
It may be possible to use the WHERE clause effectively to query the
table twice, pulling just the matching records, then perform an
unconditional cartesian on those intermediate filtered tables.

it's obvious from looking at the results-- that databases are lightning fast.
...

Think so? Given the table T containing the single numeric field N and
the records

N
1
2
3
4
5
6
7
8
9
10
11
12

try the query

SELECT T1.N AS N1, T2.N AS N2, T3.N AS N3, T4.N AS N4, T5.N AS N5,
T6.N AS N6, T7.N AS N7, T8.N AS N8, T9.N as N9, T10.N as N10,
T11.N as N11, T12.N as N12
FROM T AS T1, T AS T2, T AS T3, T AS T4, T AS T5, T AS T6, T AS T7,
T AS T8, T as T9, T as T10, T as T11, T as T12
WHERE ((T1.N Not In
(T2.N,T3.N,T4.N,T5.N,T6.N,T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T2.N Not In
(T3.N,T4.N,T5.N,T6.N,T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T3.N Not In (T4.N,T5.N,T6.N,T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T4.N Not In (T5.N,T6.N,T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T5.N Not In (T6.N,T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T6.N Not In (T7.N,T8.N,T9.N,T10.N,T11.N,T12.N))
And (T7.N Not In (T8.N,T9.N,T10.N,T11.N,T12.N))
And (T8.N Not In (T9.N,T10.N,T11.N,T12.N))
And (T9.N Not In (T10.N,T11.N,T12.N))
And (T10.N Not In (T11.N,T12.N))
And (T11.N Not In (T12.N)))
ORDER BY T1.N, T2.N, T3.N, T4.N, T5.N, T6.N, T7.N,
T8.N,T9.N,T10.N,T11.N,T12.N;

and see how fast it runs. BTW, this query adapted from one you posted
last year.

I personally think that Adobe Acrobat Reader is the worst-written piece
of software EVER. . . .

Then you've never used AOL, but I digress.

WOW. Harlan... I just saw this:

Spreadsheets are poor platforms for writing complex
systems that would be run unattended

. . .You actually admit when Excel has a weakness.

Unlike you, I know the limitations of the software I use.

I don't agree with your notion of 'properly concieved spread***
models shouldn't allow email portability'.

Where the Hell did I write that? Do you mean, "I don't see the point to
e-mail notification for PROPERLY CONCEIVED spread*** models." ? If
so, are you unaware of the difference in meaning between 'notification'
and 'portability'?

I don't believe that you have seperated what is desirable from what is
practical. I think that you are thinking inside the box.

?

I believe that these 2 concepts go hand in hand-- the ability to
schedule something to run for unattended execution--

No argument.

So are you unable to infer from this and the fact that I don't believe
Excel should be used for unattended models that I'd therefore see no
point to trying to schedule running Excel models?

and the ability to send emails programmatically.

BFD. Want some code to show you how to do this from Excel/VBA? Or are
you implying that Access can automatically send e-mail WITHOUT
attachments WITHOUT VBA?

If you're comparing Excel to SQL Server, you've lost your basis for
claiming database as end-user tool.

I believe that the ability for software to run in unattended manner is
a critical -- i mean-- absolutely critical-- requirement.
...

For what you do, it may be. You just can't conceive of anything beyond
your own ken.

Now that you agree with me-- I will drop those portions of this
discussion.

Agree with what? That spreadsheets have their limitations? When have I
ever stated otherwise? That spreadsheets shouldn't be used for
unattended tasks? Fine, we agree. However, don't think that I accept
that spreadsheets are NEVER useful. You may believe that, but I don't.

I still believe that everything out there is a report.

Failure to make distinctions, in your case allowing any
computer-generated output that's not reports, leads to incoherence.

. . . I don't
believe that Excel has 1/4 of the functionality that I need-- in order
to print pretty reports off of db-driven data.

That I don't dispute. You have different needs than most of the people
who'd use this ng. Sadly, you're unable to understand that.

And I dont think that Excel should be as popular as it is without this functionality.
...

Meaning you don't understand how Excel could be as popular AS IT IS
when you can't figure out how to use it appropriately. I feel the same
about AOL, but my wife and kids use it, so I'm stuck. This is the REAL
WORLD, we all have to work with people and things we think suck.

And spreadsheets are battleships. big and slow and dumb and
inflexible.

That's where we differ. Spreadsheets should be destroyers: small, quick
(quicker than carriers), maneuverable (certainly compared to carriers),
lightly armed, specialized, and expendable. Unfortunately, too many are
battleships built on top of a destroyer's hull, with predictable
results.

If you know anything about history; you know which type of ship is more
powerful (we lost what; 4 out of our 6 battleships at Pearl Harbor?)
...

Oh, goody! We can add historical ignorance to the other species of
ignorance you manifest. No carriers were sunk at Pearl Harbor because
none were in port on December 7, 1941. Hard to sink what isn't there.

As for carriers in the modern era, they've never been tested against
nuclear-powered attack submarines. Or cruise missiles. But feel free to
stick with your aircraft carrier metaphor.

I see that you have to do things like that all day long.
...

You have no idea what I do.

.

Quantcast