why>?

why do you guys use excel?

how do you survive the 65k row limit?
it just boggles my mind; i hate excel more than anything

i think that all your spreadsheet dorks should be homeless; on the side
of the street--

-Aaron

Because the abacus is too difficult to master.

We hate it also.
That is, until we get the no limit on rows

Many of us are homeless. Contributions are welcome.
Send all to me and I will spend it on Wild Turkey.

--
Don Guillett
SalesAid Software
[email protected]
<[email protected]> wrote in message
news:[email protected]...
> why do you guys use excel?
>
> how do you survive the 65k row limit?
> it just boggles my mind; i hate excel more than anything
>
> i think that all your spreadsheet dorks should be homeless; on the side
> of the street--
>
> -Aaron
>

Because in this newsgroup you usually meet polite and very helpfull people
Because if I have to use more than 65536 rows I use Access
Because my boss gives me a big smile when I make sth fancy for her in excel
Because that really turns me on
Because I save my coworkers many hours of work when making a nice and
usefull workbook
Because....
Because....
Because...
Because in this newsgroup you usually meet polite and very helpfull people
Because in this newsgroup you usually meet polite and very helpfull people
Because in this newsgroup you usually meet polite and very helpfull people
Because in this newsgroup you usually meet polite and very helpfull
people!!!!!!

<[email protected]> skrev i melding
news:[email protected]...
> why do you guys use excel?
>
> how do you survive the 65k row limit?
> it just boggles my mind; i hate excel more than anything
>
> i think that all your spreadsheet dorks should be homeless; on the side
> of the street--
>
> -Aaron
>

i just dont understand the value proposition.

i dont understand; do they spawn you guys in grade school?

where did you guys learn that it's socially acceptable to use this
ridiculous program??

[email protected] wrote...
>i just dont understand the value proposition.
>
>i dont understand; do they spawn you guys in grade school?
>
>where did you guys learn that it's socially acceptable to use this
>ridiculous program??

Evolution is hard. If there are a lot more Excel users than Access or
DBMS users, there'll be more Excel users to reproduce. After a few
generations, the point becomes moot. Maybe velociraptors were better
creatures by most objective criteria, but humans and rats (who share
common ancestors, for some perhaps not all that remote) have the planet
today. Fairness and objectivity have nothing to do with it.

Adapt or die.

Hello:

Because for people who know how to use a spreadsheet appropriately, the 65K limit is
meaningless. But then give the quality of the capitalizations in your post (it appears you
could not find the shift key on the keyboard) you probably would have problems with the 65K
limit.

Pieter Vandenberg


[email protected] <[email protected]> wrote:
: why do you guys use excel?

: how do you survive the 65k row limit?
: it just boggles my mind; i hate excel more than anything

: i think that all your spreadsheet dorks should be homeless; on the side
: of the street--

: -Aaron

yeah evolution is hard you idiot excel users need to evolve or die

the 65k limit is not meaningless.
it is a glass ceiling that you're stuck with and you can't do anything
about.

it's a travesty that you guys can't do anything with large datasets.

im not saying 'its not fair'

im saying that i dont understand why new people continue to get into
excel; but they won't get into Access or SQL Server.

i've never been at a company that has half of the sql server people
that we need.

but everywhere i've been; everyone knows excel.

is it the colleges that do this to us?

i just dont understand the value proposition.
i claim that if you build a database; and you build reports off of this
data; then you have the freedom to grow this into a larger, more
critical application.

i dont see oracle having an excel upsizing wizard anytime soon.

i just dont understand why you guys use excel; it seems to me like it's
a dead end street.

once you have a xls that is 10mb; what are you supposed to do with it?
you can't email it around.. you can't burn it onto a CD (since it has
countless paths to other spreadsheets; etc)

i just wish that excel had some real reporting capabilities.
i dont like shrink to fit; i think that it needs about 10x more
options.

i dont like pulling data OUT of excel. it never works.

i dont like pivotTables in Excel; they are much much much more powerful
in Office Web Components and they're faster and more portable.
i think that im going to make a real application where office web
components -- just a shell around owc where people can save their
spreadsheets in XML format TODAY.

not in office 2007.

today--

maybe i'll make an addin for access that makes owc act and behave just
like a normal form or report.

so that i can spoonfeed you kids into using a real -- tangible--
portable-- efficient system.


i just dont get the ROI that all you guys have spent millions upon
billions of hours in creating spreadsheets-- what is supposed to happen
to those spreadsheets when your company merges?

you sit there and recreate stuff by hand 24x7.

i re-use functionality; i re-use tables in hundreds of applications.

excel is worthless from what i see; and i just dont understand why
newbies use excel.

is it easier to use than accesss? NO.

is it better, longterm than access? NO.

does it scale, does it utilize multiple processors?

will excel 2007 allow 2 people to edit the same spreadsheet??

[email protected] wrote...
>yeah evolution is hard you idiot excel users need to evolve or die

The dinosaur telling the rodent to evolve. Let's just wait a bit and
count numbers of users. Won't prove which is better, but in the end
that doesn't matter.

yeah. the dinosaur is me?

you idiots copy and paste the same function a trillion friggin times a
year and you call me obsolete?

copy and paste
followed by more
copy and paste
followed by more
copy and paste
followed by more
copy and paste
followed by more
copy and paste
followed by more
copy and paste
followed by more
copy and paste


doesn't it have an endpoint?
isn't there supposed to be a happy ending for excel dorks?

how many times per day do you copy and paste?

how many excel virii have been found-- in the wild?

yes, i am a dinosaur.
in the same context that a mainframe is a dinosaur.

IBM takes databases very very seriously.

i just wish that there were more than 1 type of spreadsheet program;
maybe microsoft would have some incentives to make it better.

as it is; it's just ridiculous that microsoft hasn't added any new
funcitonaliy to excel in 10 years and you script kiddies sit there and
still use it.

if Microsoft were to take Excel-- and pull an ADP- keep all the data in
SQL Server and render is in a XLP file-- then maybe i would let you
guys keep on abusing you companies.. by submitting timecard after
timecard.. you claim that you do 'work'

when all you do is copy and paste.

you guys have thousands of copies of similiar functions; different
arguments.

if the UN were to change the calendar; and now we have 13 months-- then
all you kids will have to do about a billion things to make your
spreadsheets work.

i only have to change something in one place.

it's all about centralization; and i can do more work than 100
spreadsheet dorks.

i can leverage existing data.

you guys copy and paste existing data.

don't get me wrong-- i've seen some really really exciting solutions
using VSTO.
this is at least a step in the right direction.

but it's not fast enough ; it's not integrated-- and it's impossible to
purchase.

can't MS just include the vsto toolset with excel or something; give it
FUNCTIONALITY?

can't MS include some 'for each worksheet' functions?

i am just stunnned that the disease that is known as excel-- hasn't
been eradicated.

why doesn't the bill and melinda gates foundation give us all a vaccine
against Excel?
pay for all you kids to learn a real tool-- like SQL Server or Crystal
Reports or ASP or something?

Point made. Now, what is the purpouse of your post?

If it is for our enlightment, I would like to hear your suggestions about
how we can deal with clients/bosses that want some simple task done in Excel.
Some of the terms and expressions you have used before may not be appropiate
in those conversations, I am afraid.

Miguel.

[email protected] wrote...
>yeah. the dinosaur is me?

Got it in one! You're improving. Perhaps there's hope after all.

>you idiots copy and paste the same function a trillion friggin times a
>year and you call me obsolete?
>
>copy and paste
>followed by more
>copy and paste
>followed by more
>copy and paste
>followed by more
>copy and paste
>followed by more
>copy and paste
>followed by more
>copy and paste
>followed by more
>copy and paste

No doubt you actually typed all the forgoing.

>doesn't it have an endpoint?
....

Do your useless posts in Excel newsgroups? Entropy is forever.

>how many excel virii have been found-- in the wild?

Not all that many. More Word viruses than Excel ones because, surprise,
there are more .DOC files than .XLS files. Virus writers target the
most used applications in order to get the greatest effect. Start
giving the average business PC user more than just read access to
server-based DBMSs and you give virus writers new incentives to target
DBMSs. At the very least, Excel and Word serve as useful decoys.

>yes, i am a dinosaur.
>in the same context that a mainframe is a dinosaur.

Much more in the Control Data Corp sense than the IBM one.

>IBM takes databases very very seriously.

And it also sells a spreadsheet, Lotus 123. Your point being?

>i just wish that there were more than 1 type of spreadsheet program;
>maybe microsoft would have some incentives to make it better.

Now we agree on something. Nothing works as well as market share below
60% to get Microsoft to do anything worthwhile. Without competition,
Excel will get SmartArt and color gradients and a bigger grid that'll
cause more problems than it'll solve.

BTW, do you have any idea how many fields per table Access 2007 will
provide? Excel 2007 will have 16,384 columns. If Access doesn't keep
up, there'll be worse headaches coming.

>as it is; it's just ridiculous that microsoft hasn't added any new
>funcitonaliy to excel in 10 years and you script kiddies sit there and
>still use it.

Unfair. They added the OLAP cube interface and VBA6 in Excel 2K. Both
significant. However, nothing to warrant more than a minor version
number increase since then.

>if Microsoft were to take Excel-- and pull an ADP- keep all the data in
>SQL Server and render is in a XLP file-- then maybe i would let you
>guys keep on abusing you companies.. by submitting timecard after
>timecard.. you claim that you do 'work'
....

Ah, so you're still nonexempt. That explaims much.

>if the UN were to change the calendar; and now we have 13 months-- then
>all you kids will have to do about a billion things to make your
>spreadsheets work.
>
>i only have to change something in one place.

In the DBMS source code. Unless, of course, someone happened to
hardcode the former 12 month names for a drop-down list, in which case
you'd need to check all your forms and revise as needed.

>it's all about centralization; and i can do more work than 100
>spreadsheet dorks.
....

If only most spreadsheet users did the same, dull, dead-end grunt work
you do.

>can't MS include some 'for each worksheet' functions?
....

You mean something other than

For Each ws In SomeWorkbook.Worksheets

?

Does VSTO completely ignore Excel's object model, or are you just
ignorant of what Excel's OM provides?

Just wait till you see the copy/paste when there are more rows than access.


--
Don Guillett
SalesAid Software
[email protected]
"Harlan Grove" <[email protected]> wrote in message
news:[email protected]...
> [email protected] wrote...
>>yeah. the dinosaur is me?
>
> Got it in one! You're improving. Perhaps there's hope after all.
>
>>you idiots copy and paste the same function a trillion friggin times a
>>year and you call me obsolete?
>>
>>copy and paste
>>followed by more
>>copy and paste
>>followed by more
>>copy and paste
>>followed by more
>>copy and paste
>>followed by more
>>copy and paste
>>followed by more
>>copy and paste
>>followed by more
>>copy and paste
>
> No doubt you actually typed all the forgoing.
>
>>doesn't it have an endpoint?
> ...
>
> Do your useless posts in Excel newsgroups? Entropy is forever.
>
>>how many excel virii have been found-- in the wild?
>
> Not all that many. More Word viruses than Excel ones because, surprise,
> there are more .DOC files than .XLS files. Virus writers target the
> most used applications in order to get the greatest effect. Start
> giving the average business PC user more than just read access to
> server-based DBMSs and you give virus writers new incentives to target
> DBMSs. At the very least, Excel and Word serve as useful decoys.
>
>>yes, i am a dinosaur.
>>in the same context that a mainframe is a dinosaur.
>
> Much more in the Control Data Corp sense than the IBM one.
>
>>IBM takes databases very very seriously.
>
> And it also sells a spreadsheet, Lotus 123. Your point being?
>
>>i just wish that there were more than 1 type of spreadsheet program;
>>maybe microsoft would have some incentives to make it better.
>
> Now we agree on something. Nothing works as well as market share below
> 60% to get Microsoft to do anything worthwhile. Without competition,
> Excel will get SmartArt and color gradients and a bigger grid that'll
> cause more problems than it'll solve.
>
> BTW, do you have any idea how many fields per table Access 2007 will
> provide? Excel 2007 will have 16,384 columns. If Access doesn't keep
> up, there'll be worse headaches coming.
>
>>as it is; it's just ridiculous that microsoft hasn't added any new
>>funcitonaliy to excel in 10 years and you script kiddies sit there and
>>still use it.
>
> Unfair. They added the OLAP cube interface and VBA6 in Excel 2K. Both
> significant. However, nothing to warrant more than a minor version
> number increase since then.
>
>>if Microsoft were to take Excel-- and pull an ADP- keep all the data in
>>SQL Server and render is in a XLP file-- then maybe i would let you
>>guys keep on abusing you companies.. by submitting timecard after
>>timecard.. you claim that you do 'work'
> ...
>
> Ah, so you're still nonexempt. That explaims much.
>
>>if the UN were to change the calendar; and now we have 13 months-- then
>>all you kids will have to do about a billion things to make your
>>spreadsheets work.
>>
>>i only have to change something in one place.
>
> In the DBMS source code. Unless, of course, someone happened to
> hardcode the former 12 month names for a drop-down list, in which case
> you'd need to check all your forms and revise as needed.
>
>>it's all about centralization; and i can do more work than 100
>>spreadsheet dorks.
> ...
>
> If only most spreadsheet users did the same, dull, dead-end grunt work
> you do.
>
>>can't MS include some 'for each worksheet' functions?
> ...
>
> You mean something other than
>
> For Each ws In SomeWorkbook.Worksheets
>
> ?
>
> Does VSTO completely ignore Excel's object model, or are you just
> ignorant of what Excel's OM provides?
>

Don

Excel will NEVER hold more rows than Access.

I have a billions rows in access-- all the time.

I use Access Data Projects-- the grown-up version of Access.

-Aaron

[email protected] wrote...
>if you have customer data and it doesnt live in a database
....

Geez, you're dense!

Not customer tracking or historical transaction data. THEIR nonpublic
financial information that's most definitely not accessible OUTSIDE
THEIR company by ANY connection to THEIR databases, and often subect to
NDAs that essentially PREVENT storing any of THEIR data in any of my
company's databases. THEIR data may come from their databases or maybe
(gasp! shudder!) from their spreadsheets, but provided to me/my company
in the form of e-mail or attachments, never yet in the form of MDB
files and seldom in tabular form, and most definitely NOT AVAILABLE
from MY company's databases.

But this is likely wasted bandwidth since you seem incapable of
understanding that any company works with any data other than what
rolls in from POS or inventory systems. You also seem incapable of
understanding that some business share nonpublic financial data as part
of negociating pricing for certain long-term financial services
contracts. One company's nonpublic financial information damn well
better NOT be available in OTHER comapnies' databases. So this leads to
a concept that you may not be capable of comprehending: businesses
share data without using databases to do so, and often there are legal
obligations NOT to store it in widely accessible databases.

Becoming obvious no one has ever let you come close to important data.

>CRM, outlook-- all that ****-- keeps data in a database where it
>belongs.
....

Not CRM data. Next guess.

>I run my own consulting business.

Not much work right at the moment, eh?

[email protected] wrote:
> why do you guys use excel?
>
> how do you survive the 65k row limit?
> it just boggles my mind; i hate excel more than anything
>
> i think that all your spreadsheet dorks should be homeless; on the side
> of the street--
>
> -Aaron
>
Welcome back, Aaron! Where have you been?
Did you rant about Lotus 1-2-3 many years ago?

Bill

[email protected] wrote...
....
>a) i dont believe that you have mountains and mountains of data that
>are strictly prohibited from going inside a database. if you do then
>your customers are idiots.

Wrong. My customers are sensible, so am I, and you're an ignorant idiot
who simply has no basis in your own experience for handling data
without a database, so you react in classic fight or flight mode
because you're out of your depth.

My customers' data is in THEIR databases, but I as an employee of
ANOTHER company DO NOT have access to THEIR databases. Do you know
anything about database security and/or US corporation law with respect
to sharing nonpublic financial information with outsiders that might
help you figure out why this may be a desirable state?

>b) even if you do you're a ******* idiot because earlier we
>demonstrated that excel virii are a scourage-- making Excel
>UN-FRIGGIN-USABLE

Proved?! Where? Provide a link.

Perhaps in your own imagination, but that ain't proof.

>c) keeping your data in a spreadsheet in your machine is THUS MORE OF A
>THREAT than keeping it in a database

If it were YOU 'managing' the data, you'd have a point.

>d) if you keep your DATA in tabular form-- in CSM form-- in email
>attachments; any of that-- it is TRIVIAL to get it inside a db.

Trivial but more often than not pointless if the analysis takes place
in a spreadsheet. Which brings us back to another black hole in your,
er, knowledge: calculations involving either recursive or nested
formulas, i.e., stuff databases can't handle without multiple, possibly
nested, queries. And when the number of such nested queries depends on
the data, it requires nontrivial stored procedures to do what
spreadsheet can handle with relatively simple formulas.

>you're not FASTER at excel than i am with databases.

No, I suppose you could kill forests' worth of reports faster than I
could generate a few numbers. The question remaining is whether the
tons of printout you generate is worth more than the handful of numbers
I produce. Kinda like comparing fertilizer with diamonds - the
principal basis for comparison is value rather than weight or weight
per time unit. I grant you generate much more fertilizer more quickly
than I can.

>Just because i 'only work with databases' lol (you written any ASP
>*******? php? .net?)

ASP and PHP, nope. .Net, yup, but rarely.

You written any Perl, R, SAS, IBM JCL, WSH scripts coordinating the
execution of all of them?

>just because i only work with databases-- that doesn't mean i 'only
>work with inventory databases' or 'pos databases'
....

I suppose you can handle name & address databases for generating form
letters too.

So when do you grow up? Maturity realizes there are different needs, and
doesn't despise those who fill a different position. You sound like a
teenager whose daddy bought him a big truck -too bad the size of the vehicle
has nothing to do with the size of the person driving it.

I learned Excel just a few years ago because that's what all the people in
my company use, because that's what those they interacted with used. I am
not capable of changing things on that large of a scale. So I learned Excel
and VBA, and have earned some awards within my company for providing Excel
applications to them. Excel fits their need, so that's what I gave them.
Excel was within my grasp at that time, so that's what I've learned. Is
there more out there with bigger and better functions? Sure - and if I need
to I'll learn it. If I don't have to, then why?

Besides, if working with _your_ program makes you that immature, then I'll
stick with Excel and the good people here who've helped me along the way.

Ed

<[email protected]> wrote in message
news:[email protected]...
>I have a billions rows in access-- all the time.
>
> I use Access Data Projects-- the grown-up version of Access.
>
> -Aaron
>

1) cartesian data
2) build cubes
3) drag and drop

all of a sudden; presto chango--

I DONT NEED ANY WORTHLESS BEANCOUNTERS ANYMORE!!!!

Why don't you spend your extra time and energy helping those who need it in
an Access newsgroup?
Why are you trying to sell ice to Eskimos?
Why?
Why?
Why?

Beege

<[email protected]> wrote in message
news:[email protected]...
> why do you guys use excel?
>
> how do you survive the 65k row limit?
> it just boggles my mind; i hate excel more than anything
>
> i think that all your spreadsheet dorks should be homeless; on the side
> of the street--
>
> -Aaron
>

And,

Why so acerbic?

Beege

<[email protected]> wrote in message
news:[email protected]...
> why do you guys use excel?
>
> how do you survive the 65k row limit?
> it just boggles my mind; i hate excel more than anything
>
> i think that all your spreadsheet dorks should be homeless; on the side
> of the street--
>
> -Aaron
>

RE:

1 1 1
1 1 2
1 1 3
1 2 1
1 2 2
1 2 3
1 3 1
1 3 2
1 3 3
2 1 1
2 1 2
2 1 3
2 2 1
2 2 2
2 2 3
2 3 1
2 3 2
2 3 3
3 1 1
3 1 2
3 1 3
3 2 1
3 2 2
3 2 3
3 3 1
3 3 2
3 3 3


only 6 of which are permutations of the original set


1 2 3
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1

here's my goddamn solution ok buddy?

create table N
(N INT NOT NULL)
go
insert into n(n)
values (1)
go
insert into n(n)
values (2)
go
insert into n(n)
values (3)

then if you want your precious little permutations

Select N1.N N1, N2.N N2, N3.N N3
>From N N1, N N2, N N3
Where N1.N <> N2.N AND N1.N <> N3.N AND N2.N <> N3.N
order by 1, 2, 3



sorry.. I didn't understand that you assumed that cartesianing is
always out of control complete and utter cartesianing.

you see; you can combine a join and a whereclause with some
cartesianing in order to control the result set.

yeah go ahead and block me.
i speak the truth

If I am the only person that has sat you idiots down and said 'grow up
and get a real skillset' then I am fine with making a couple babies
cry.

WAHHHHHHHHHHHHHHHHHHHH
WAHHHHHHHHHHHHHHHHHHHH
WAHHHHHHHHHHHHHHHHHHHH


and im sorry your virgin ears

CANT HANDLE THE TRUTH

and for the record??

I keep a table called N and a table called C in almost every database i
make.
i add these to the model database in SQL Server; and then when I make a
new db they already exist.

if you're all worried about adding different size sets; etc-- i can
just filter these further with the where clause.

it's not rocket science; it's called 2nd grade math instead of the
pre-schooler math that you spreadsheet dorks chew on.

-Aaron

re:
No, data exists independent of storage medium/mechanism. But not
surprising that you're limited worldview can't cope with that.


no Harlan-- you're wrong.

Data-- Nice-- Usable-- Reliable Data-- shouldn't be stuck in data
islands and duplicate copies.
how many copies of the same data do you keep; Harlan?

Hundreds?

What happens when you need to change a calendar to account for a new
national holiday?
you have to sit there and loop through hundreds of spreadsheets and
copy and paste stuff until you turn blue.

THAT IS CALLED A WASTE OF TIME.

Data should be centralized and LEVERAGED so that you're automagically
10% exponentially faster the next time you run the same report-- you've
already got the infrastructure there.

it's like you kids and trying to build the empire state building-- and
you're using LEGOs.

don't carry a blanket around with you every day
don't suck on your thumb

and DONT USE EXCEL FOR REPORTING AGAINST DATABASES. IT ISN'T
FUNCTIONAL ENOUGH TO BE USED FOR A SINGLE SMALL ONE-TIME REPORT.

[email protected] wrote...
>re:
>No, data exists independent of storage medium/mechanism. But not
>surprising that you're limited worldview can't cope with that.
>
>no Harlan-- you're wrong.
>
>Data-- Nice-- Usable-- Reliable Data-- shouldn't be stuck in data
>islands and duplicate copies.
>how many copies of the same data do you keep; Harlan?
....

First, acording to you there was no data before the UNIVAC post WW2. It
may be the case that you'd be at a complete loss for how to do anything
(even find your butt with both hands) if you didn't have a database to
help you do so.

Few if any. You may not know how to use spreadsheets competently, but
there are at least a few million people around the world who can.

>What happens when you need to change a calendar to account for a new
>national holiday?

What idiot, aside from you, keeps a calendar in Excel? If you mean with
regard to the NETWORKDAYS or WORKDAY functions, you obviously don't
know how to use workbook templates and store shared read-only files on
file servers. Put commonly used data, such as company holiday lists, in
named ranges in a workbook, save that workbook read-only in a server
share, create workbook templates with defined names referring to named
ranges in the shared workbook as external references. Change all such
templates by changing the server file once.

To repeat, that you don't know how to use Excel competently implies
nothing about whether there are or aren't MANY Excel users who are MUCH
MORE competent.

>you have to sit there and loop through hundreds of spreadsheets and
>copy and paste stuff until you turn blue.
....

Or use a canned macro written years ago to make batch changes iterating
through a table of affected workbook files and a table of range
addresses and replacement formulas. If you're not competent to
administer Excel models . . .

>Data should be centralized and LEVERAGED so that you're automagically
>10% exponentially faster the next time you run the same report-- you've
>already got the infrastructure there.
....

10% exponentially faster?! More random verbiage.

And if only all work were generating reports.

>and DONT USE EXCEL FOR REPORTING AGAINST DATABASES. IT ISN'T
>FUNCTIONAL ENOUGH TO BE USED FOR A SINGLE SMALL ONE-TIME REPORT.

Thanks. I'll keep that in mind if I ever have to create reports again.

[email protected] wrote...
>RE:
....
>here's my goddamn solution ok buddy?
>
>create table N
>(N INT NOT NULL)
>go
>insert into n(n)
>values (1)
>go
>insert into n(n)
>values (2)
>go
>insert into n(n)
>values (3)

The forgoing so much easier than creating a list in Excel.

>then if you want your precious little permutations
>
>Select N1.N N1, N2.N N2, N3.N N3
>From N N1, N N2, N N3
>Where N1.N <> N2.N AND N1.N <> N3.N AND N2.N <> N3.N
>order by 1, 2, 3

Finally!

Very good.

Except that the Where clause grows factorially. Becomes a bit of a pain
to handle 8 distinct tokens using

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
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
WHERE ((T1.N<>T2.N) And (T1.N<>T3.N) And (T1.N<>T4.N) And (T1.N<>T5.N)
And (T1.N<>T6.N) And (T1.N<>T7.N) And (T1.N<>T8.N)
And (T2.N<>T3.N) And (T2.N<>T4.N) And (T2.N<>T5.N) And (T2.N<>T6.N)
And (T2.N<>T7.N) And (T2.N<>T8.N)
And (T3.N<>T4.N) And (T3.N<>T5.N) And (T3.N<>T6.N) And (T3.N<>T7.N)
And (T3.N<>T8.N)
And (T4.N<>T5.N) And (T4.N<>T6.N) And (T4.N<>T7.N) And (T4.N<>T8.N)
And (T5.N<>T6.N) And (T5.N<>T7.N) And (T5.N<>T8.N)
And (T6.N<>T7.N) And (T6.N<>T8.N)
And (T7.N<>T8.N))
ORDER BY T1.N, T2.N, T3.N, T4.N, T5.N, T6.N, T7.N, T8.N;

Then there's runtime. Your query's comparison operations make this an
O((N+1)!) procedure. Table-driven permutation generation, such as found
in

http://groups.google.com/group/micro...1e73ffd974b4d2

will be much faster for 8 or more distinct tokens.

>sorry.. I didn't understand that you assumed that cartesianing is
>always out of control complete and utter cartesianing.
>
>you see; you can combine a join and a whereclause with some
>cartesianing in order to control the result set.

OK, so you're not using the strict, Codd definition. Fine. You don't
use much other terminology in the strict sense, so silly me for
expecting otherwise.

Harlan. I know you are having fun but your blood pressure is going up. Let's
quit feeding the troll. He has been here before for food.

--
Don Guillett
SalesAid Software
[email protected]
"Harlan Grove" <[email protected]> wrote in message
news:[email protected]...
> [email protected] wrote...
>>re:
>>No, data exists independent of storage medium/mechanism. But not
>>surprising that you're limited worldview can't cope with that.
>>
>>no Harlan-- you're wrong.
>>
>>Data-- Nice-- Usable-- Reliable Data-- shouldn't be stuck in data
>>islands and duplicate copies.
>>how many copies of the same data do you keep; Harlan?
> ...
>
> First, acording to you there was no data before the UNIVAC post WW2. It
> may be the case that you'd be at a complete loss for how to do anything
> (even find your butt with both hands) if you didn't have a database to
> help you do so.
>
> Few if any. You may not know how to use spreadsheets competently, but
> there are at least a few million people around the world who can.
>
>>What happens when you need to change a calendar to account for a new
>>national holiday?
>
> What idiot, aside from you, keeps a calendar in Excel? If you mean with
> regard to the NETWORKDAYS or WORKDAY functions, you obviously don't
> know how to use workbook templates and store shared read-only files on
> file servers. Put commonly used data, such as company holiday lists, in
> named ranges in a workbook, save that workbook read-only in a server
> share, create workbook templates with defined names referring to named
> ranges in the shared workbook as external references. Change all such
> templates by changing the server file once.
>
> To repeat, that you don't know how to use Excel competently implies
> nothing about whether there are or aren't MANY Excel users who are MUCH
> MORE competent.
>
>>you have to sit there and loop through hundreds of spreadsheets and
>>copy and paste stuff until you turn blue.
> ...
>
> Or use a canned macro written years ago to make batch changes iterating
> through a table of affected workbook files and a table of range
> addresses and replacement formulas. If you're not competent to
> administer Excel models . . .
>
>>Data should be centralized and LEVERAGED so that you're automagically
>>10% exponentially faster the next time you run the same report-- you've
>>already got the infrastructure there.
> ...
>
> 10% exponentially faster?! More random verbiage.
>
> And if only all work were generating reports.
>
>>and DONT USE EXCEL FOR REPORTING AGAINST DATABASES. IT ISN'T
>>FUNCTIONAL ENOUGH TO BE USED FOR A SINGLE SMALL ONE-TIME REPORT.
>
> Thanks. I'll keep that in mind if I ever have to create reports again.
>

[email protected] wrote...
>what you're missing is that SQL Server is better than this.
>it doesn't actually calculate each possible row and then filter them
>out.

It doesn't generate each tuple, but it does have to perform
comparisons.

Try generating some tables with 12 to 20 distinct values, time how long
it takes the queries to run, then plot those run times.

>i can out-develop you harlan.
....

In databases and web pages, probably. Financial simulation models, I
doubt it.

>screw you-- just because you took a couple of programming classes
>doesn't make you an expert.
....

As opposed to you CLAIMING you're an expert? Any proof?

A simple Google Groups search shows that your postings in database ngs
are usually as vacuous as your postings in this ng.

[email protected] wrote...
>who cares about non-wintel systems?
>
>sql server owns the olap market www.olapreport.com and their database
>is quite strong these days.
>
>IIS has made great strides; IIS 7 is going to make it even more
>critical to use a real OS for web servers
....

Netcraft still shows more than 2.5 times as many web sites running
Apache as running IIS. Facts (as opposed to 'data') are such awkward
things.

First of all, HI TO EVERYONE!!! Quit every argument will you?? I had both knowledge of access and excel. They are good and bad. But whats the point of arguing when you don't even need to worry for your client and boss (who might be using either one)?? You will still survive with the kowledge you have now right? The quarrel you all having now is like "Is Jesus a human?" (no offence) . They are prove that both are right and wrong. Just satisfy yourselve and let this matter rest. No point straining yourselves trying to find a bad point of other program when you don't appreciate judgement other made for the program you using. To end the case why don't everyone just take the "opinion" and close the case ? Anyway, by arguing don't provide us food and money.

First of all, HI TO EVERYONE!!! Quit every argument will you?? I had both knowledge of access and excel. They are good and bad. But whats the point of arguing when you don't even need to worry for your client and boss (who might be using either one)?? You will still survive with the kowledge you have now right? The quarrel you all having now is like "Is Jesus a human?" (no offence) . They are prove that both are right and wrong. Just satisfy yourselve and let this matter rest. No point straining yourselves trying to find a bad point of other program when you don't appreciate judgement other made for the program you using. To end the case why don't everyone just take the "opinion" and close the case ? Anyway, by arguing don't provide us food and money.

Originally Posted by noob2

First of all, HI TO EVERYONE!!! Quit every argument will you?? I had both knowledge of access and excel. They are good and bad. But whats the point of arguing when you don't even need to worry for your client and boss (who might be using either one)?? You will still survive with the kowledge you have now right? The quarrel you all having now is like "Is Jesus a human?" (no offence) . They are prove that both are right and wrong. Just satisfy yourselve and let this matter rest. No point straining yourselves trying to find a bad point of other program when you don't appreciate judgement other made for the program you using. To end the case why don't everyone just take the "opinion" and close the case ? Anyway, by arguing don't provide us food and money.

sorry for this double reply... Com lag... HAHA

there is no such thing as 'financial simulation models'

all there is is data and i use the right tool; you use a crutch.

and because of this you have the capabilities of a 3rd grader.

[email protected] wrote:
[snip weapons grade balonium]
> excel is a girly-man program.

Heh heh. That's why I can consistantly bill $85/hr doing
development in it. Heh heh.
Socks

oh boy.. $85 huh??

big spender, big spender

just because you con people into using it doesnt mean it's worth.

you and the other 100m spreadsheet dorks in the world-- altogether the
worth of every spreadsheet created by every spreadsheet dork.. is equal
to ZERO.

there has never been a single spreadsheet developed that is worth a
penny.

Is that so?!? I wonder how much does each table in access cost... Everything has a price my friend. There is nothing call worthless and priceless... Its human that make it that way accroding to their needs. So there is no good or bad, only need or dun need.

listen idiot do you really believe that anyone uses netscape for
anything anymore??

Yep, idiot, some of us do, becuase we hate most things MS.

Except Excel, of course.

-)

[email protected] wrote:

> listen idiot do you really believe that anyone uses netscape for
> anything anymore??
>

wow you guys are really stuck in the 90s.

it makes me sick to think that you guys get paid for copying and
pasting; your company should hire a bunch of monkeys-- literally

hammering away with a big button that says copy and a big button that
says paste.

they could build the same **** you do but they woudln't be such a PITA


and seriously

you dumbshits have never written a webpage in your lives; so why in the
**** do you guys give a **** about apache vs iis?

furthermore; does this show what is being used for INTRANET sites?


INTRANET sites-- where a user in an office can talk to a web
applicaiton without having to sign-in every 30 seconds-- is almost
exclusively the domain-- pun intended-- of IIS.

IIS allows you to authenticate and double-hop authentication i mean

apache doesnt even come close to this same functionality

but the point of the matter is that if you dipshits knew how to spell
HTML you would be writing webpages and not jerking off to microsoft
excel
so who gives a flying **** what you guys say?

i respect apache

apache and php-- even mysql is a great product.

but in real - world -- corporate implementations?

they suck ballz compared to iis.

i just think that it's hilarious that you guys sit there and talk ****
about MS.
when you smoke MS pole every day by using this diseased program called
Excel.

the worst program; the worst time-waster-- ever written.

grow some balls and start doing databases kids; you'll be amazed that
**** gets easier for you and you're not stuck with a billion documents
filled with spaghetti code references.

excel is just impossible to manage.

one of these days i'll get my application working again-- called 'grade
your beancounter'

and i'll give all you fucktards a big fat F for productivity.

-Aaron

seriously

i just find it laughable that you sit there and in response to my 'why
do people use excel' question; you start ranting and raving about
apache.

why is excel used?
who started this disease?
when is there going to be a terminator movie about someone travelling
back in time and blowing up the early excel

the world would be a much better place

robots aren't the problem

excel-- copying and pasting the same formula in 2000 different places;
this is by defintiion-- unmanageable.

how do you guys cope with cutting and pasting functions around like
this??
are there tools for automating this?

i know excel like the back of my hand i've just never 'gotten it'

how do you guys stay productive in excel?
is ms going to have a real certification track for excel in the future?

i mean a tiered, industry-specific certification track

[email protected] wrote...
>>And in well-designed spreadsheet models, what would all these people be
>>trying to do at the same time? . . .

Not only do you seem to know little about spreadsheets (*PROVE*
otherwise), you also seem to be ignorant of standard USENET quoting
conventions (I've backfilled). Need a pointer to a USENET faq?

>It doesn't ******* working for multiple users

Neither do calculators. Once you realize most *well-designed*
spreadsheet models are little more than glorified programmable (and
programmed) calculators, understanding may dawn. I won't hold my
breath, though.

Are spreadsheets MISused as databases? Yup. Are they MISused as
calendars? Yup again. Are they MISused by most users most of the time?
Probably, because they tend to be the *ONLY* automatable software with
relatively flexible *and* simple layout capabilities given to most
business computer users. That doesn't mean they can't be used
appropriately and well, but few if any companies spend money training
employees how to use Office or other 'productivity' software.

[email protected] wrote...
>i do know excel fucktard

Prove it.

>i do know excel fucktard

PROVE IT!

>i choose not to use it because it gave me carpal tunnel
>copy and paste is no fun for me anymore

Oh, too bad. Convenient, though. Like saying in a bar, "Yeah, I used to
be able to run a mile in under 4 minutes before my accident." Sounds
good. Doesn't mean much.

>everything you do is a 'report' buddy
....

No. More accurate would be the only thing you can understand is
reporting. Anything more complicated is beyond your comprehension.

[email protected] wrote...
>i just find it laughable that you sit there and in response to my 'why
>do people use excel' question; you start ranting and raving about
>apache.

Read the archives. You're the one who starts these tangents, usually
making unfortunate statements that can easily be proved false. Some of
the rest of use point out those errors in order to give indications of
your BS to sense ratio. And you have a very, very high BS ratio.

>why is excel used?

Because that all MOST business users have. You're also incapable of
understanding that while many business users have Access RUNTIME, they
don't have the full Access product. And, no, corporate Office licenses
aren't mostly for Professional. In the company where I work, fewer than
5% of users overall have Access. The percentage is higher in some
departments than others. In several departments, NO ONE has Access.

>who started this disease?
....

Um, guess you'd have to blame Bricklin and Frankston, perhaps Kapor and
Sachs too. Don't give Microsft credit/blame for starting this.
Microsoft doesn't innovate (at least not outside programming
languages/environments), but they're damn good at copying.

>when is there going to be a terminator movie about someone travelling
>back in time and blowing up the early excel
....

If you saw T3, you know the future is inevitable. Get used to it.

>is ms going to have a real certification track for excel in the future?

Excel is a calculator. Where's the certification track for the HP 12-C?
Top end spreadsheet users do things like setting up hedging strategies
for large corporations. They use Excel as one tool among many. Their
certification is their PhDs or MBAs. They need Excel certification as
much as lawyers need Word and WestLaw certification, or as much as
carpenters need saw and hammer certification.

> i mean a tiered, industry-specific certification track

Who needs it?

Besides, *IF* there were any money in it, Microsoft would have done it
LONG AGO. Unlike you, Microsoft focuses on realistic potential revenue.

[email protected] wrote...
>why do you guys use excel?
....

This seems apt.

http://www.regdeveloper.co.uk/2006/0...ends_database/

Harlan

Just because I dont like excel; does that mean i dont know it?

that's the most conceited thing i've ever heard.

oh yeah?
2 can play at that game

http://www.regdeveloper.co.uk/2006/0...y_spreadsheet/

How many scenarios can you imagine where a momentary loss of
concentration could cost over $1bn? Perhaps a nuclear power station
meltdown...or if a currency trader hit a few wrong keys? Well, another
possibility is a simple spreadsheet error.

In October 2003, soon after announcing third quarter earnings, Fannie
Mae had to restate its unrealised gains, increasing them by $1.2bn.
This highly unwelcome outcome was said to stem from "honest mistakes
made in a spreadsheet used in the implementation of a new accounting
standard".

The really, really bad news is that millions of similar errors are
almost certainly being made every year, many of them in
business-critical financial spreadsheets. Although they are the
quintessential end-user tool, spreadsheets of any complexity are just
as hard to write and maintain as any other kind of software - if they
are to yield consistently accurate results, anyway.


-----------------------------------------------------------------
HOW DO YOU LIKE ME NOW *****?
-----------------------------------------------------------------

[email protected] wrote...
>Just because I dont like excel; does that mean i dont know it?

Then try responding in other threads with *EXCEL* solutions to OP's
problems. Show us you know something about Excel. After all, there's no
..advocacy in this ng's name.

http://www.fmsinc.com/tpapers/genaccess/DBOD.asp

Millions of databases are created in Excel spreadsheets each year, but
only a tiny percentage "graduate" to the next level: Access.


Lots of Data is Stored in Excel
Even though Excel is not a database, in many organizations, people
store more data in spreadsheets than any other platform. This drives IT
professionals crazy, but works. Decision makers need to analyze data
and they know Excel. This is one of the greatest benefits of desktop
computing.

Although Excel is not a relational database, it solves many simple
database problems completely. That's because many database problems
can be solved with simple database solutions. Only a tiny percentage of
Excel spreadsheets ever reach the limits of Excel, but when they do,
many should migrate to Access.

Microsoft Access Fills a Large and Important Segment
The success of Access as the most popular database in the world is a
testament to its capabilities and the pervasive need for database
solutions by productivity workers. Access is the first weapon of choice
when it comes to relational databases because of its ability to quickly
create useful database solutions.

It may not have all the features scalability, performance, reliability,
and security of more sophisticated solutions, but for many situations,
those features are irrelevant or secondary to what Access offers.
Access offers an excellent solution for database challenges facing
individuals, small teams, and workgroups across a network.

The number of database challenges within an organization that can be
solved by Access is much larger than solutions solved by more complex
and expensive solutions. And over time, with the drop in hardware
prices and increases in performance, more and more database situations
are solved by Access.


Quantity of Database Solutions
As illustrated in the Database Pyramid, there are a lot more small
databases than large ones. Here's an estimate of the relative number
of database solutions by platform in a large organization:

Platform
Quantity

Excel
50,000

Access Individual
5,000

Access Simple Multi-user
1,000

Access Department
500

VB/Jet
100

VB/VS.NET/Java and SQL Server
50

Oracle, IBM db2
25

SAP, Tandem, etc.
10


Integrates with Microsoft Office
Access is part of Office and integrates with the most popular interface
users use: Office. Enabling users to view data and exporting it into
Excel or Word (or users simply pasting it themselves) is extremely
powerful to knowledge workers.

Great for Data Entry - ****Windows Still Beats Web****
Somehow web users are trained to accept behavior that would cause howls
in Windows applications. For instance, changing the quantity and
pressing [Update] to refresh total sales. Access easily (cheaply)
supports this, copying and pasting records, displaying multiple
one-to-many relationships, and other basic features (e.g. spell
checking) that provide a much friendlier and richer data entry
experience than Web solutions.


Most Database Problems are Small
Most database problems manage relatively small amounts of data and
usually well under 100 MB. This is well within Access' strength and
using a product like SQL Server would be overkill for such small
amounts of data (SQL Server does offer features that might be important
beyond database size).

<-- THIS ARGUMENT IS BS SINCE I USE ACCESS DATA PROJECTS; ACCESS
APPLICATIONS THAT SCALE TO HUNDREDS OF USERS WITHOUT A PROBLEM.
SQL Server Eliminates the Scalability Issue
Microsoft has designed Access to be scalable. Access applications can
eliminate Jet and use SQL Server as its data repository. Access
databases (MDBs) can link to SQL Server data, and ADPs work directly
against SQL Server. SQL Server eliminates the scalability issue for
data size and number of users.

When people focus on the limitations of Access scalability, it's
important to note that the issue is really about the Jet Database
Engine, and not Access as the front-end to SQL Server. Of course it
takes extra work to migrate to SQL Server or convert an MDB to ADP, but
a significant portion of the development investment is preserved.


------------------------------------------------
More than 95+% of Access databases created by end users will never
require IT department intervention.
------------------------------------------------

So harlan-- your highness-- what in the hell are you talking baout how
'db development is the domain of it'



Evolution of Access Developers
Most Access developers evolved from non-programming professions. They
fell into Access, discovered the amazing productivity gains, learned
VBA, and become more and more sophisticated. Over time, they move from
being more business oriented to programming becoming VB or .NET
developers using SQL Server. These people now consider Access
applications trivial.

But the change is with the person and not Access. Access still does
what it does well but that person is ready to move on. They now look
down on people like their former selves challenged by database
fundamentals they now take for granted. They forget they've become
the people in the IT shop that their former selves tried to avoid, and
that Access was their gateway to their successful career. Their
evolution away from Access is okay, even expected, as others follow in
their footsteps discovering the amazing solutions they can create with
Access.

[email protected] wrote...
>oh yeah?
>2 can play at that game
>
>http://www.regdeveloper.co.uk/2006/0...y_spreadsheet/
....

Where have I ever said spreadsheets were error-free?

Besides, there's another Reg article about the Malasian telephone
company sending some customer a bill for more than the country's GDP.
Wanna bet whether that bill was generated by a database? Errors are
possible in EVERY software system.

The article I cited was about the pathologies and lack of mental
balance of database developers. Still applicable.

[email protected] wrote...
>you're full of **** you guys all need certifications.

Mine's an MA in math. Excel-specific certification as unnecessary for
my job as calculator certification. And since you're so set on the
necessity of certification, where'd you be if the world's most
successful college dropout hadn't been able to start Microsoft because
he lacked any formal certification?

>there is no way to determine whether someone is worth six figures for
>making spreadsheets.
....

Yes there is, but you won't be able to figure it out.

>you dorks should be upheld to the same standards as real developers-- i
>mean-- you guys waste more money than the real developers do

Real developers like who? Most of the really important developers
weren't formally schooled in programming (Bill Gates, Dennis Ritchie,
Edsger Dijkstra, Donald Knuth - Ken Thompson, Bill Joy and James
Gosling are probably the major exceptions), and none were certified in
anything other than that implicit in their academic qualifications.
Certification is for mediocre developers . . . like you.

[email protected] wrote...
....
>Databases aren't the domain of IT.

Perhaps not, but software installation is. If the IT department won't
install something, it could be a firing offense to install it oneself.

If the typical user lacks database development software, what does s/he
do? Whine about it in newsgroups or use what's available?

>Excel can't even do simple math correctly and reliably.

?

Do you mean most Excel users make formula errors?

The spreadsheet bugs you've cited elsewhere have nothing to do with
Excel making errors evaluating correct formulas. There are problems
with several functions, but they're shared by a great many other
software packages, likely including Access and SQL Server. For evample,
with the table T containing one field named V and records as so

V
100000000
100000001

the query

SELECT Var(V)
FROM T;

returns 0 as the result. It should be 0.5. Guess Access is a buggy as
Excel.

>And I honestly don't use 1/10th of what I learned.
....

I think the figure is much, much less.

so what it's forcing a round down when it takes the average?? im not
sure that is a bad thing.

i just claim with source control tools-- with notepad for christ
sakes-- it is quite easy; it is quite possible to make sure that a
database has accurate information.

on the other hand garbage in = garbage out.

the thing with excel.. is if you feed it garbage in you dont even get
ANYTHING out.

excel is a waste of breath; a waste of hard drive space.
the 2nd biggest security threat ever.
and 100 times more of a time-waster than either internet explorer or
solitaire.

you can accomplish things with databases

with spreadsheets all you can do is jerk off and make worthless
documents.

i tell you this-- it is entirely possible to judge the value of a
company based on their computer systems.

if i ever work for wall street again; i'd like to go around to
companies and say 'let me see your schema'

so that i can get a sense of whether a company has direction

or whether it's just a bunch of flaky spreadsheet dorks.

i mean what the hell harlan

you sit there and make the same damn spreadsheet week in and week out.

may your children reek of underberries
and you trip and fall and smash your head on the accident when you wake
up

may your dogs hide every left sock
so you have to wear a mismatch



because for all i know you are THIEVES and stealing from your
companies.

you don't do anything valuable; you don't add a penny in value to your
company.

you sit there and make the same ******* spreadsheet 10 times a year.

i am outraged that you think that you guys matter.



what i mean to ask is-- why are you idiots too ******* stupid to grow
up and learn a real program?

learn something that creates value; i dont care if it's photoshop-- you
can draw your ******* graphs for all i care.
i get all the 'analytics' i need with a freeware stack called 'Analysis
Services' and 'Office Web Components'

i dont need people to sit around and crunch numbers.

i feed more numbers to more people that you guys could possibly fathom.


I have the solution for your addiction to spreadsheets.


i encourage all you guys to drop out-- get rid of excel--
learn databases; build olap

and presto chango; you've got the best reporting solution that money
could buy.

it's free-- it's better pivot Tables than your typical XLS pivotTables.

they're faster, more scalable; more powerful; more portable

there isnt' a reason in the world to use XLS files.

OWC. Office Web Components-- spreadsheet control and pivotTable
control; it's time to start thinking outside the box kids

time to lose the training wheels



I haven't ever worked in a department where the tech doesn't walk up
and give me admin priveleges.
i dont need to ask for it. they just see me and can telepathically
assume that i know what the hell im doing and they bend over and give
me admin priveleges.


maybe if you weren't considered 'just a spreadsheet wimp' you wouldn't
get denied local admin

it's called freedom of though

get out of excel kids

[email protected] wrote...
>so what it's forcing a round down when it takes the average?? im not
>sure that is a bad thing.

No, it's floating point truncation error caused by using a simplistic
one-pass algorithm. And for the record, Microsoft did fix this in Excel
2003. And FWLIW, Lotus 123 never shared this problem; 123 always used a
better algorithm.

>i just claim with source control tools-- with notepad for christ
>sakes-- it is quite easy; it is quite possible to make sure that a
>database has accurate information.
....

It's possible to ensure spreadsheets have accurate information, though
not using Notepad. BTW, how do you open terabyte-size database files in
Notepad?

>the thing with excel.. is if you feed it garbage in you dont even get
>ANYTHING out.
....

Which, if it were true, would be a good thing. No results are better
than false ones.

>excel is a waste of breath; a waste of hard drive space.

Evidently, Excel is sufficient reason for you to keep posting.

>the 2nd biggest security threat ever.
....

Proof? Was it Excel or Word this week that Microsoft had to tell the
world & dog to run in safe mode?

Behind Outlook?

>i tell you this-- it is entirely possible to judge the value of a
>company based on their computer systems.
....

Enron and their auditor had some well-respected systems. Lots of value
there. Or did I transpose the s and t?

>i am outraged that you think that you guys matter.
....

That's probably true. It must be frustrating not understanding what
anyone who doesn't develop database apps does.

>I haven't ever worked in a department where the tech doesn't walk up
>and give me admin priveleges.
>
>i dont need to ask for it. they just see me and can telepathically
>assume that i know what the hell im doing and they bend over and give
>me admin priveleges.
....

Since you couldn't really do the sort of work you claim to do without
admin priviledges, it'd be rather pointless to hire you and not give
you them. But 99% of the non-IT and non-developer/consultant workforce
doesn't get any admin priviledges.

im trying to save you guys; saying anything other than 'dont use excel'
is a lie

Oh Harlan, Thank you, thank you, You have made my day. After reading your
responses to Aaron's posts, I could not stop laughing. You obviously have
Aaron outmanned and outgunned. My question to Aaron is, if he hates XL, and
all XL "dorks" (I beleive was the term used).. Then why is he even here? He
sure spends alot of his time hanging out "chatting" with the HATED XL users.

Anyway,
Harlan take care and keep up the good work.

Harlan Grove wrote:
>[email protected] wrote...
>>why do you guys use excel?
>...
>
>This seems apt.
>
>http://www.regdeveloper.co.uk/2006/0...ends_database/

im here because i need to convince you guys to stop smoking crack
before crack version 2007 comes out

smoking crack might be fun today; but what about tomorrow morning when
you've got a dozen spreadsheets lying around and you can't LEVERAGE
these into anything useful?

crack is whack and so is excel

[email protected] wrote...
>internally; sql server can support huge numbers; so i dont accept your
>claim.
>
>much larger numbers than Excel can hold lol

As usual, you're wrong because you're ignorant. In this case, you're
ignorant of the specifications of the data types SQL Server provides.
Let me hlep you.

http://msdn2.microsoft.com/en-US/library/ms187752.aspx

Follow the links for all the numeric data types. SQL Server's Real
corresponds to VBA's Single, and SQL Server's Float corresponds to
VBA's Double and Excel's *only* numeric data type. The latter group are
all IEEE double precision floating point reals.

So, what are you talking about?

And of course you don't accept my claim because it'd undercut your
arguments as well as provide yet more proof you're clueless when it
comes to calculations more complicated than checkbook register math.

>it's not possible to verify spreadsheets. it is impossible to apply
>software-development tools to excel-- and since 90% of the developers
>at your company are 'spreadsheet developers' it is not practical to
>double-check each and every formula, value and formatting.

You know how many developers there are at my company? Name it. Name
some of them. Or are these more empty claims and/or blather?

>i have worked on countless spreadsheet aggregation projects-- etl
>technically-- and im sick and tired of working with a tool that doesn't
>have
>
>a) accurate, provable functions and formulas

No function is 'provable' without source code *and* empirical testing.
Since Microsoft provides no publicly available source code for the
functions in any of its produces, Excel's functions are as unprovable
as SQL Server's.

As for formulas, it takes work, but it involves writing cell formulas
to text files in R1C1 addressing syntax, grouping cells that should
contain the same formulas, and verifying that the formulas are in fact
identical. That just proves consistency. The next and final step is
checking that each distinct formula does what it should. That can be
tedious for very long formulas, but not impossible.

>b) accurate and strict data entry controls

You mean valid/reasonable entry. Inaccurate but technically valid
and/or reasonable entry is possible with any software, even databases.

It takes VBA, specifically, [Sheet]Change event handlers and validation
formulas. Neither prevent invalid entries up front, only catch them and
reverse them once made. Note that spreadsheets aren't unique in lacking
transaction capabilities that databases provide. That is a strength of
databases relative to spreadsheets. However, transactions don't prevent
all errors.

>c) portable method for transferring large amounts of data
....

Portable? Like ODBC? Every .XLS file may be an ODBC data source. As
such, any application capable of querying ODBC data sources could
consolidate data in .XLS files.

>i find it laughable that you talk to a database person like a junior--
>WE MOVE MORE NUMBERS IN AN HOUR THAN YOU DO IN A WEEK
....

Movers carry more PCs around than I do, but that doesn't make them
programmers. You move more numbers. You just don't understand what
those numers mean.

People who move stuff will always be able to find jobs working for the
people who know why that stuff needs to be moved.

[email protected] wrote...
>I'm talking about bigints you fucktard
>bigint Integer data from -2^63 through 2^63-1

Which would be useless for storing noninteger data. And which wouldn't
affect the Var query function, which needs to work with double
precision floating point values.

>bigint; close enough to a google that i'll never need to go that high..
....

Probably. And integers are relatively worthless for most physical and
statistical
calculations, so you might as well be using strings. In case you can't
figure this out, what's the average of the bigints 12345678901234567890
and 12345678901234567891? How do you represent the average *EXACTLY* in
any SQL data type?

>'oh but i have to use 9 points of precision because we balance against
>the euro market every night and i have to copy and paste all these
>formulas around'
....

More examples needed? Long term bond yields require exponentiating 1
plus fractional interest rate several times, each time eating more of
the available, finite precision. Many bits of precision are needed in
order to calculate the current yields with reasonable accuracy. Also,
any simulation analysis involving long tails or catastrophes would be
dealing with probability values between .999999 and 1.0. Fortunately,
those of us who haven't forgotten most of the math we learned in school
are familiar with transformations which shift the calculations so that
they can use more of the fixed precision available. However, Access
doesn't, at least not with respect to its Var query function.

>All i have to do is check the formula once per column.
>you have to check it once per cell.
....

If I were doing it manually. However, with just a few tools, it's
usually necessary to test only one R1C1 formula per multiple column,
multiple row range.

>I'll just disable macros and you won't be able to do a damn thing about
>it.
....

Standard approach to dealing with this is using do-nothing udfs, e.g.,

Function donothing() : End Function

to add or append to all validation formulas. When macros are enabled,
Excel will treat the value returned by this function the same as the
value of blank cells, as zero when used numerically or "" when used as
text.

When macros are disabled, *ALL* udfs return #NAME? errors. With
validation formulas evaluating to errors, all formulas should also
evaluate to errors in properly written spreadsheets. If all formulas
evaluate to and display errors, the printouts aren't going to be very
useful.

That does lead to the question whether Excel workbooks can be secured
against *intentional* user manipulation. They can't. Excel lacks the
security features to prevent intentional changes by sophisticated
users.

>or if you use excels' data type validation i will just copy and paste
>values to get around that.
....

Not me. I use dropdown lists, but only as data entry shortcuts, not for
validation. In the workbooks I write, validation rules are calculated
in defined names.

Originally Posted by [email protected]

im here because i need to convince you guys to stop smoking crack
before crack version 2007 comes out

smoking crack might be fun today; but what about tomorrow morning when
you've got a dozen spreadsheets lying around and you can't LEVERAGE
these into anything useful?

crack is whack and so is excel

erhm aaron, If we transfer all the excel data into access will it still become rubbish??? Im sure you are smart enough to know that data that is not usable in excel, when transfer into any database, you still get rubbish.

Im not here to convince you that excel is good,
BUT
if you wanna compare using database, excel can do it.
if you wanna compare UI, excel can do it.

It their business to continue using excel. You can say all you want but you still cant stop them or even their superior to stop using excel. That is of course if you plant virus in all excel worksheet or hack all the worksheet making them notice that it is not good in using excel. [That depend on how good your hacking is...]

there is one more possibly to stop people from using excel. That is MS stop providing excel. CAN YOU DO IT ?

Sheesh! This mental midget named Aaron must have just discovered Access. Also, he looks like he never did any more with Excel than what's on the surface, so to speak. Wonder if his boss knows how much time he's wasting on forums mumbling and ranting abouth things that he is definitely ignorant about?

Last but not least, it takes a real moron to use his e-mail address as a user name.... guess he couldn't figure how to set up a user name.... he probably thought he'd have to do it in Excel.

The person needs to get a life...... any kind of life. Must've had a downer childhood!

In article <[email protected]>,
greaseman <[email protected]>
wrote:

> it takes a real moron to use his e-mail address as a user name....
> guess he couldn't figure how to set up a user name.... he probably
> thought he'd have to do it in Excel.

Not sure what you mean, here...

Only a rather small minority of posters use excelforum to post to
newsgroups.

Many of us read from and post directly to the news servers, and so don't
need a "username". Using a newsreader is much faster than having to go
through a web forum, and it's much more convenient, IMHO.

Using an alias is recommended by MS, since spambots harvest email
addresses, but my email provider does a fine job of screening spam, so
I'd rather give people a way to reach me if they want to. And using a
"username" that's not related to my real name seems a bit juvenile to
me. YMMV, of course.

If that makes me a "real moron", so be it...

?? Not sure what you're discussing..... my comments were concerning the moron, Aaron and his inability to come up with a user name in the forum. I haven't used newsgroups for quite a while and simply thought this was a forum, not a newsgroup.

In anycase, the moron Aaron has ranted and raved on this forum and I doubt if he too would know anything about newsgroups, since he's already demonstrted his lack of knowledge about other things so well. What I was getting at was the fact that he didn't have the knowledge or ability to give himself a user name and instead stupidly used his e-mail address.

Every forum I have used highly recommends an e-mail address should not be used or given, unless spam is desired. I am happy for you that your e-mail provider takes care of your e-mail.... they must have figured out enough algorithms and routines to "cut through" a lot of spam.

Juvenile or not, most forum members use some sort of User Name concept.

"If that makes me a "real moron", so be it..." - no comment, since I was discussing user names, not newsgroups, and secondly was discussing the moron Aaron and his lack of tact and intelligence.

As you can see I use my real name and my real email address. Gets business.

--
Don Guillett
SalesAid Software
[email protected]
"greaseman" <[email protected]> wrote
in message news:[email protected]...
>
> ?? Not sure what you're discussing..... my comments were concerning the
> moron, Aaron and his inability to come up with a user name in the
> forum. I haven't used newsgroups for quite a while and simply thought
> this was a forum, not a newsgroup.
>
> In anycase, the moron Aaron has ranted and raved on this forum and I
> doubt if he too would know anything about newsgroups, since he's
> already demonstrted his lack of knowledge about other things so well.
> What I was getting at was the fact that he didn't have the knowledge or
> ability to give himself a user name and instead stupidly used his e-mail
> address.
>
> Every forum I have used highly recommends an e-mail address should not
> be used or given, unless spam is desired. I am happy for you that your
> e-mail provider takes care of your e-mail.... they must have figured out
> enough algorithms and routines to "cut through" a lot of spam.
>
> Juvenile or not, most forum members use some sort of User Name
> concept.
>
> "If that makes me a "real moron", so be it..." - no comment, since I
> was discussing user names, not newsgroups, and secondly was discussing
> the moron Aaron and his lack of tact and intelligence.
>
>
> --
> greaseman
> ------------------------------------------------------------------------
> greaseman's Profile:
> http://www.excelforum.com/member.php...o&userid=28808
> View this thread: http://www.excelforum.com/showthread...hreadid=544465
>

Ok, OK.... Anyway, the main thrust of my response to this thread was to imply that Aaron doesn't know what he is talking about in regard to Excel, and that his rantings indicated a perceived lack of experience and personality, and to imply that someone who does that type of junk on a forum most likely will receive a bunch of not nice e-mail, since he was using his e-mail address as his user name.

Apparently, choosing to use an e-mail address as opposed to a user name is a choice of the member. Personally, I prefer to get forum responses through the way I've got my profile set up, to receive a notice that someone has replied to me.

But, again, each to their own.

BTW, Aaron does appear to be a moron.

In article <[email protected]>,
greaseman <[email protected]>
wrote:

> ?? Not sure what you're discussing..... my comments were concerning the
> moron, Aaron and his inability to come up with a user name in the
> forum. I haven't used newsgroups for quite a while and simply thought
> this was a forum, not a newsgroup.

Ah. I assumed that the disclaimer on ExcelForum's home page:

> Usenet Groups
> These forums are gateways to selected excel related usenet newsgroups.

would let everyone know that they were posting to newsgroups... My
mistake.

> In anycase, the moron Aaron has ranted and raved on this forum and I
> doubt if he too would know anything about newsgroups, since he's
> already demonstrted his lack of knowledge about other things so well.

I suspect he knows full well. His problem is not a lack of knowledge,
per se...

> What I was getting at was the fact that he didn't have the knowledge or
> ability to give himself a user name and instead stupidly used his e-mail
> address.

Hard to pick a username when you're not using a "forum". I can't really
fault him for that...

> Every forum I have used highly recommends an e-mail address should not
> be used or given, unless spam is desired. I am happy for you that your
> e-mail provider takes care of your e-mail.... they must have figured out
> enough algorithms and routines to "cut through" a lot of spam.

Yup.

> Juvenile or not, most forum members use some sort of User Name
> concept.

OK. I haven't been a forum member since my CompuServe days in the mid
'80s, so I wouldn't know.

> "If that makes me a "real moron", so be it..." - no comment, since I
> was discussing user names, not newsgroups, and secondly was discussing
> the moron Aaron and his lack of tact and intelligence.

Aaron's a troll, certainly, and he's got some real people-skills issues,
but he's hardly a moron or unintelligent.

Many of the points he makes are quite valid - people use XL for things
that are far more easily and securely handled by a database application.
But he goes off the deep end when he refuses to admit that some things
*are* more easily handled by XL, and some things that XL can do that a
database app cannot (at least without inordinate contortion).

Generally, calling people names says as much about the name-caller than
about the named. That's true in Aaron's case too.

Perhaps my musings were misinterpreted, I don't know - in effect, I am saying Aaron is moronic and definitely lacks communication skills; as far as any points he made concerning Excel, they were countered by his rantings and language along the way. He struck me as bigoted against Excel and also as quite immature.

..."Aaron's a troll, certainly..."

I agree with what you said: "Generally, calling people names says as much about the name-caller than about the named...." That applies whether the name called is a moron or a troll.

i still disagree that there is a single task that is 'faster' or
'easier' in excel than in a database.

you can sit there and say 'yeah but this throw-away report' and crap
like that

BUT WHEN YOU SIT THERE AND BUILD THE SAME REPORT WEEK IN AND WEEK OUT??
I MEAN SERIOUSLY HERE KIDS

a) it's not throw-away if you do the SAME DAMN SPREADSHEET WEEK IN AND
OUT.
b) i can still do throw-away faster in access (adp) than you kids can
in excel
c) i can take backups of my applications-- while i am writing them. you
can't backup spreadsheets while they're open.
d) i have version control tools. you don't.
e) i scale to multiple processors and i can utilize large amounts of
memory.
f) sub-second response times against billions of records. Olap has
made all you kids obsolete...
In other words; there aren't ANY performance problems using
databases. there haven't been performance problems for 10 years.
g) you diseased-*** losers are going to 'feel more justified' in using
excel when your row limit is gone and you can save reports to XML
format.
THIS DOESNT FIX THE PROBLEM THAT YOU ALL STILL BUILD ISLANDS
INSTEAD OF MOUNTAINS.

And your point is, besides the one on your head?

This is apples and oranges, since Excel is a spreadsheet-type application and Access is a database application, and besides that, WHO CARES what you think?

".....sub-second response times against billions of records. " Really? How? I've worked in companies, large and small, where tons of records have crippled Access, as well as having several users hitting a database at the same time has also crippled Access.

Perhaps you do know both Excel and Access, but most of your responses and musings in this forum are a bit simpleton and extremely prejudiced. You sound like, "Nyaaaa, nyaaaa, I can do this better than you can!" That is only because as I said earlier, one is oriented toward spreadsheets and one is oriented toward database processing.

If you don't care for Excel, then don't use it and please find another newsgroup / forum to harass.

[email protected] wrote...
>you couldn't physically use formulas to VALIDATE other formulas if your
>life depended on it.
....

Read carefully. I didn't mention formulas to validate formulas. It's
formulas to validate entries. Whether those entries are constants of
formulas is immaterial. Only their values matter. And, yes, formulas in
spreadsheets can be used to validate entries, both by ensuring proper
data types and reasonable ranges of values.

>i never write the same formula twice-- if it's something i reuse i will
>write it as a UDF and then i can use it all the time without breaking
>my wrist in copying and pasting.
>when i change the formula-- i only need to change it in one place.
....

Kinda pointless to use udfs for simple expression transformations,
e.g., bump up values by 5%, but that's inventory cost in one table,
sales price in another, and projected revenues in a third.

>I can audit my data with formulas; but i dont have to write a different
>formula for each cell

Neither do I. The beauty of [Ctrl]+[Enter].

>PS -- does this allow you to prevent numeric fields?
>Which is why you should use validation formulas. If no cells in some
>range (RNG, say) should contain strings, use a validation formula like
>=COUNTIF(RNG,"*")=0.
>
>Does this prevent you from putting a value in a cell that is negative?

Now you're changing the specs, but still simple enough.

=SUMPRODUCT(COUNTIF("Rng",{"*","<=0"}))=0

>you can't REACT to changes in data.
....

You may not be able to outside databases. Doesn't mean no one else
does.

>it is EASY for me to send an email when a record in a db changes.
>
>it is EASY for me to send an email when data is missing.
....

E-mail being pointless if input is manual, as it often is in
spreadsheets. Simpler to use formulas to display warning and error
messages telling the user what's wrong and how to correct the invalid
entries.

>you have to sit around and wait for the data.. . . .
....

True, if you mean wait for the user to enter something. That's just how
spreadsheets work. But simple enough to react immediately after entry.

>i can script through long-running jobs and preprocess numbers at night.
....

Big deal. So can I. So can anyone who knows how to automate the
software they use.

>i can schedule my jobs.. can you?

Manual data entry, no. Complex simulation modeling, yes, even including
pulling data from electronic sources (even databases) during execution.

As you can see aaron, MS is not stupid to create something that is so useless as you say. Of course, being a newer program do have ABIT of adventage but that adventage does not always benefits people. In the end, there is still both user in the world. And WHY ARE YOU SO KEEN TO ASK EXCEL USER TO JOIN YOU??? MS sent you to influence them so that they can stop excel support izzt??? haha...

In response to:

> Ah. I assumed that the disclaimer on ExcelForum's home page:
> Usenet Groups
> These forums are gateways to selected excel related usenet newsgroups.
> would let everyone know that they were posting to newsgroups... My
> mistake.

And I assumed that both the site name and the first tree node of this web site implied a Forum.... http://www.excelforum.com and "Excel Help Forum" ..... my, my, how silly of me to think that meant Forum, when everyone knows it means newsgroup.

> Hard to pick a username when you're not using a "forum". I can't really
> fault him for that...

I guess it's really hard to pick a user name when the second page of the registration process specifies that a user name should be chosen. Do "newsgroup users" register in a different way?

> That applies whether the name called is a moron or a troll.

Very true. The difference *for me* is that "troll" describes a
demonstrable *behavior*, validated in Aaron's case by any number of
posts which serve only to inflame, disrupt, and invite impassioned
responses. That behavior usually, but not always, is done for the power
that the troll feels when people respond to them, which is why one
should never feed them if one wants them to go away.

On the other hand, a moron is a person of low intelligence, which is a
personal *characteristic*, and in the case of Aaron, is demonstrably
false. I find Aaron's posts obnoxious, and offensive, and often
juvenile, but he's clearly not stupid.

Perhaps I'm drawing a distinction without a difference for you. If so,
I'm sorry for wasting your time.

In any case, this now has nothing to do with XL, so the thread should
probably end.




In article <[email protected]>,
greaseman <[email protected]>
wrote:

> Perhaps my musings were misinterpreted, I don't know - in effect, I am
> saying Aaron is moronic and definitely lacks communication skills; as
> far as any points he made concerning Excel, they were countered by his
> rantings and language along the way. He struck me as bigoted against
> Excel and also as quite immature.
>
> .."Aaron's a troll, certainly..."
>
> I agree with what you said: "Generally, calling people names says as
> much about the name-caller than about the named...." That applies
> whether the name called is a moron or a troll.

Here is a web definition of moron: [From Greek mōron, neuter of mōros, stupid, foolish.] I had in mind the second description, i.e., foolish.

And true, we shouldn't respond to a Troll, especially such a moronic one.

> In any case, this now has nothing to do with XL, so the thread should
probably end.

Agreed, so let's let this moronic troll wither on the vine. Fun while it lasted.

my posts are inflammatory?

you dipshits are the ones that are attacking ME
not attacking my argument you idiots attack ME

and then you sit there and call me inflammatory?

go play with your baby toys kids

this post is about excel
it is about how excel is a toy for retarded kids

copy and paste
and
copy and paste

tell me about the rabbits, george

copy and paste

grow some balls kids learn a real tool.

crystal reports for all i care.





JE McGimpsey wrote:
> > That applies whether the name called is a moron or a troll.
>
> Very true. The difference *for me* is that "troll" describes a
> demonstrable *behavior*, validated in Aaron's case by any number of
> posts which serve only to inflame, disrupt, and invite impassioned
> responses. That behavior usually, but not always, is done for the power
> that the troll feels when people respond to them, which is why one
> should never feed them if one wants them to go away.
>
> On the other hand, a moron is a person of low intelligence, which is a
> personal *characteristic*, and in the case of Aaron, is demonstrably
> false. I find Aaron's posts obnoxious, and offensive, and often
> juvenile, but he's clearly not stupid.
>
> Perhaps I'm drawing a distinction without a difference for you. If so,
> I'm sorry for wasting your time.
>
> In any case, this now has nothing to do with XL, so the thread should
> probably end.
>
>
>
>
> In article <[email protected]>,
> greaseman <[email protected]>
> wrote:
>
> > Perhaps my musings were misinterpreted, I don't know - in effect, I am
> > saying Aaron is moronic and definitely lacks communication skills; as
> > far as any points he made concerning Excel, they were countered by his
> > rantings and language along the way. He struck me as bigoted against
> > Excel and also as quite immature.
> >
> > .."Aaron's a troll, certainly..."
> >
> > I agree with what you said: "Generally, calling people names says as
> > much about the name-caller than about the named...." That applies
> > whether the name called is a moron or a troll.

[email protected] wrote...
>A) properly conceived spreadsheet models
>IS AN OXYMORON.
>
>what do you mean by PROPER?

Models that perform a lot of calculations with possibly a lot of
*static* data and a little user-entered data. One example, something I
built, takes up to 14 entries from the user and uses some of those
entries as weights to produce cashflow patterns which are provided to
customers in PDF files (company policy; if you don't like it, bang your
head against a wall until the feeling passes). Behind the scenes the
calculations involve lookup, interpolation and weighted averaging.
Simple but tedious.

All users do is make the entries and write PDF files. There are 2 free
form text entries (unvalidated - my users are on their own for spelling
customer etc names correctly), 6 dropdown lists (validated to the
extent that if users enter anything not in the lists, all formulas
return errors and messages appear next to those cells explaining what's
wrong), and the remaining 6 are two separate sets of 3 percentage
entries with each set also having a formula equal to one less the sum
of the 3 entries. If any, including the formulas, are nonnumeric or
outside the range 0 to 100%, messages appear beside the formula cells
and all other formulas evaluate to errors.

It's a glorified calculator. Users don't save hundreds of copies of the
workbook, though there is a separate copy on each regional office's
file server. It does generate lots of PDF files, but since these files
are intended for different customers, that's not a problem.

Could this be provided by a web page? Probably, but there'd need to be
some user authentication, and that'd need to be something that would be
able to prevent people who've recently quit working for customers and
gone to work for competitors (a situation that occurs not infrequently)
from accessing this information. Yes, they could take existing PDF
files with them, but they could also take photocopies of other
sensitive material. However, the goal would be to prevent them from
creating NEW exhibits using different entries. So unless our customers'
personnel databases were linked to our user authentication process,
it's safer to keep this offline.

This is something that *IS* easier to do with spreadsheets than
databases. It's POSSIBLE to do it with either, but it's EASIER with
spreadsheets. Try dabbling with interpolation to see why. Given tables
of quarterly cashflow percentages, that is, each quarter has a
percentage between 0 and 100%, and the sum of quarterly cashflows over
all quarters is always 100%, users can select semiannual, quarterly,
monthly and weekly cashflows (with standard simplifications: each
quarter has 3 equal duration months and 13 equal duration weeks).
Semiannual cashflows are sums of two sequential quarterly cashflows,
but monthly and weekly cashflows are linearly interpolated between
quarters. Granted you could store each type in database tables, but
there's a trade-off between storage and calculation time. Besides, the
same thing goes on in databases when views are used rather than tables.

>B). I can do excel macros; i've written hundreds and thousands of pages
>of them. I dont see the point in trying to knock me Harlan. I know
>excel. And I hate it. Is it that hard to understand?
....

I understand the claims you're making, but I don't believe them. Prove
it. I don't doubt you could tweak recorded macros and apply generic
techniques that would work with other applications using VB*. But I'm
unconvinced you know how to use Excel's object model efficiently or
intelligently.

>I DONT DO LOW-LEVEL STUFF I DEVELOP INTERFACES FOR DATAMARTS,
>DATAWAREHOUSES. I automate 20 servers at a time.

More unsubstantiated claims.

>I DISAGREE WITH YOU. . . .

No?! Really?!

> . . . Get off your high horse; everything that you do
>in excel is repetitive. Everything that you print is a report.

How predictable. Everything Aaron can conceive of is a report. Or
should that be the only thing Aaron understands is reports. So all
computer output is reporting, ergo all computer usage is report
generation.

> . . . Contracts are nothing more than reports; retard. . . .
....

Predicted that response, didn't I?

Only you would asert such an absurdity. Only you might believe it. Gee,
I hope you have the opportunity to see whether this is true or not.

Next you'll be telling us all marketing material and advertising are
reports. After that, all literature is reports. Anything that could be
[re]produced with a computer and a printer is a report. Proof via
reductio ad absurdum that you're an idiot.

>I DISAGREE WITH YOU. Databases aren't unnecessarily 'complex'.
>Databases don't need IT. Support Infrastructure-- Warning
>Mechanisms... Just because you had an email fail once; is it the
>databases fault?
....

More manufactured BS. When did I claim any e-mail failure? I don't see
the point to e-mail notification for PROPERLY CONCEIVED spreadsheet
models. To make this clear, I believe spreadsheet models should be
interactive. Spreadsheets are poor platforms for writing complex
systems that would be run unattended. Even for models in which the
unattended runtime would just be very long recalc, if spreadsheet
models take more than 30 seconds to recalc, they shouldn't be
implemented as spreadsheets.

If you're right that databases aren't unnecessarily complex, wouldn't
your time be better spent showing poor benighted Excel users how to
solve their problems using databases? That is, if your goal were
convincing Excel users to switch to databases. There have been annoying
Perl solutions in many other languages' newsgroups over the years, so
off-topic solutions have a USENET tradition even if they are contrary
to proper netiquette. 'Course that'd assume you COULD provide any sort
of solution to any of the questions posed in this ng. That's unproven.

storage isn't a concern anymore harlan

catalogs, contracts, manuals--- all that stuff is easily written using
a real reporting tool.
Personally I think that everyone from Eddie Bauer to lawyers offices--
should throw out everything that they do-- and rewrite stuff in Access.

I mean-- what better way to build a database-driven catalog; than to
use a db-reporting tool? I argue that Access is better and making
pretty flyers than publisher or word.

I argue that I could write a book in Access; and it would be easy to
manage.
Instead of having hundreds and thousands of manual formatting in Word
or Excel--you build a template; and Access generates stuff for you on
the fly.

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.

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.



db aren't complex; there isn't a single task in the world that is
easier to do in a spreadsheet than it is to do in Excel.


i have provided lots and lots of solutions.

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

I still think that is the root of our miscommunicaton.

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.

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

I just think that you should be doing more to automate.
Instead of keeping data in documents; instead of copying and pasting
stuff from webpages-- why don't you source data into a database and
then re-use it??

if you can do it today and you have to re-do it tomorrow-- why not make
a multi-user application where people can all enter their budgeting
information at the same time?

with excel; you can't scale the workload to multiple people.
that is probably my biggest complaint about Excel-- is that multiple
people can't work in the same XLS at the same time.

and I dont have a beef with PDF any longer. Adobe is guaranteed a
future because they bought macromedia.

I personally think that Adobe Acrobat Reader is the worst-written piece
of software EVER. imagine excel-- worthless little program-- that is a
TSR and about twice as bloated.

I mean-- it takes 60 friggin seconds to open?
and then it sits around in my memory?

it is ridiculous.

i mean-- how many times do i have to bring up task manager to kill out
of adobe acrobat reader?

I can produce portable reports in PDF form quite easily.. just as
easily as you. Technically; I can use one Adobe Acrobat license for 20
users and you have to purchase one license per desktop.

To be even more honest-- Adobe Acrobat costs the same as Microsoft
Access; so if push comes to shove; i sure wouldn't spend $100 per seat
to further a monopoly.
I would look for 3rd party alternatives..

a) export reports to SNP format.
b) have a centralized machine 'print' SNP to PDF
c) rinse and repeat.

WOW. Harlan... I just saw this:

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

this right here-- it gives me a 40% more respect for you (meaning your
total respect percentage is about 37% altogether). You actually admit
when Excel has a weakness.

I don't agree with your notion of 'properly concieved spreadsheet
models shouldn't allow email 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--

and the ability to send emails programmatically.

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

Have you seen the movie 'Brazil' is it (it might be 1984; I can't
remember)? Rows and rows of people sitting around; pushing
calculators?? Rows and rows of people; even robots-- sitting around and
typing stuff into calculators?

it is hilarious I think.

Right now; you proved that you are tethered to your desktop; tethered
to copy + paste in ways that just aren't problems in the db world.

That is why I say things like 'i get more done by 2am than you do all
day'

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

I respect and thank you for continuing to talk these things over with
me.
i just honestly don't understand where people get in the habit of using
Excel.

I just don't understand it-- in the big picture of things.

Is it taught in colleges?


I still believe that everything out there is a report. And I dont
believe that Excel has any functionality for reporting. 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.

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

If and when Excel has a capability to send a portable report-- that is
when i begin to see a drop of value in Excel. If Excel could spit out
PDFs; that had embedded data-- then Excel would be a dream come true.

(I'm not talking about this crap MDI format-- i mean; microsoft just
ISNT ALLOWED to change portable document formats 3 times in 5 years).

As it is; i just don't understand the value proposition.

It's like-- I build aircraft carriers-- where my mothership databases
can launch little tiny reports-- portable reports that are easy to
format.

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

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?)

I honestly wish that I understood a lot more about how to minimize file
sizes in Excel.
If i could find a book that is specific to that topic-- then I might
see more value in Excel.

As it is; i just see thousands and thousands of formulas-- that are 80%
the same with different arguments.

And I dont think that things are that complex in the db world.

I don't -- in the db world-- need to write formulas-- for row 273; i
dont need to hard-code '273' in any of my formulas.

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

So i just see the difference between Excel and databases-- that
databases don't NEED to store a different formula for each row.

And that is why I believe that they are 10,000 times more efficient
than Excel.

If i have a couple of tables (5 tables, 1000 rows each); and I render
these in 30 different slices--

from my understanding..

5 tables
1000 rows in each
100 characters per row -or- 10 columns of 10 characters each.

in a db world-- i have one copy of the data and 30 queries. Total
storage requirements = 5x1000x100 characters per row + 30 sql
statements (100 chars each) =
500,000 DATA
3,000 FORMULAS
503,000 TOTAL CHARACTERS.

in excel -- i have one copy of the data and 30 queries. Total storage
requirements = 5x1000x100 characters per row + 30 worksheets of
formulas (50 chars each formula, ) = 500,000 DATA
15,000,000 Formulas (30 sheets X 10,000 cells X 50 chars/ formula) =

15,500,000.

I just don't understand-- how and why-- your report takes 15,500,000
characters.
and my report takes 503,000 characters.

I mean-- if we include indexes-- I dont index as much as other db
people because I'm an Olap nut (and Olap is effectively the same as
indexing)

So if we do include indexes; and we index the snot out of my db-driven
solution.. then maybe we're stuck with 1,003,000 characters vs.
15,500,000 characters.

I just don't understand-- it boggles my mind-- how verbose Excel is.

Please-- correct me where I am wrong-- I want to get to the bottom of
this..

-Aaron


PS - I do believe that Access reports are a better tool for printing
than Excel. I just feel like the whole 'shrink to fit' feature results
in fonts that are unreadable in many situations-- and instead of
shrinking everything; i wish that Excel had the capability to stretch
data NORTH-SOUTH or even to just shrink a single cell.






Harlan Grove wrote:
> [email protected] wrote...
> >A) properly conceived spreadsheet models
> >IS AN OXYMORON.
> >
> >what do you mean by PROPER?
>
> Models that perform a lot of calculations with possibly a lot of
> *static* data and a little user-entered data. One example, something I
> built, takes up to 14 entries from the user and uses some of those
> entries as weights to produce cashflow patterns which are provided to
> customers in PDF files (company policy; if you don't like it, bang your
> head against a wall until the feeling passes). Behind the scenes the
> calculations involve lookup, interpolation and weighted averaging.
> Simple but tedious.
>
> All users do is make the entries and write PDF files. There are 2 free
> form text entries (unvalidated - my users are on their own for spelling
> customer etc names correctly), 6 dropdown lists (validated to the
> extent that if users enter anything not in the lists, all formulas
> return errors and messages appear next to those cells explaining what's
> wrong), and the remaining 6 are two separate sets of 3 percentage
> entries with each set also having a formula equal to one less the sum
> of the 3 entries. If any, including the formulas, are nonnumeric or
> outside the range 0 to 100%, messages appear beside the formula cells
> and all other formulas evaluate to errors.
>
> It's a glorified calculator. Users don't save hundreds of copies of the
> workbook, though there is a separate copy on each regional office's
> file server. It does generate lots of PDF files, but since these files
> are intended for different customers, that's not a problem.
>
> Could this be provided by a web page? Probably, but there'd need to be
> some user authentication, and that'd need to be something that would be
> able to prevent people who've recently quit working for customers and
> gone to work for competitors (a situation that occurs not infrequently)
> from accessing this information. Yes, they could take existing PDF
> files with them, but they could also take photocopies of other
> sensitive material. However, the goal would be to prevent them from
> creating NEW exhibits using different entries. So unless our customers'
> personnel databases were linked to our user authentication process,
> it's safer to keep this offline.
>
> This is something that *IS* easier to do with spreadsheets than
> databases. It's POSSIBLE to do it with either, but it's EASIER with
> spreadsheets. Try dabbling with interpolation to see why. Given tables
> of quarterly cashflow percentages, that is, each quarter has a
> percentage between 0 and 100%, and the sum of quarterly cashflows over
> all quarters is always 100%, users can select semiannual, quarterly,
> monthly and weekly cashflows (with standard simplifications: each
> quarter has 3 equal duration months and 13 equal duration weeks).
> Semiannual cashflows are sums of two sequential quarterly cashflows,
> but monthly and weekly cashflows are linearly interpolated between
> quarters. Granted you could store each type in database tables, but
> there's a trade-off between storage and calculation time. Besides, the
> same thing goes on in databases when views are used rather than tables.
>
> >B). I can do excel macros; i've written hundreds and thousands of pages
> >of them. I dont see the point in trying to knock me Harlan. I know
> >excel. And I hate it. Is it that hard to understand?
> ...
>
> I understand the claims you're making, but I don't believe them. Prove
> it. I don't doubt you could tweak recorded macros and apply generic
> techniques that would work with other applications using VB*. But I'm
> unconvinced you know how to use Excel's object model efficiently or
> intelligently.
>
> >I DONT DO LOW-LEVEL STUFF I DEVELOP INTERFACES FOR DATAMARTS,
> >DATAWAREHOUSES. I automate 20 servers at a time.
>
> More unsubstantiated claims.
>
> >I DISAGREE WITH YOU. . . .
>
> No?! Really?!
>
> > . . . Get off your high horse; everything that you do
> >in excel is repetitive. Everything that you print is a report.
>
> How predictable. Everything Aaron can conceive of is a report. Or
> should that be the only thing Aaron understands is reports. So all
> computer output is reporting, ergo all computer usage is report
> generation.
>
> > . . . Contracts are nothing more than reports; retard. . . .
> ...
>
> Predicted that response, didn't I?
>
> Only you would asert such an absurdity. Only you might believe it. Gee,
> I hope you have the opportunity to see whether this is true or not.
>
> Next you'll be telling us all marketing material and advertising are
> reports. After that, all literature is reports. Anything that could be
> [re]produced with a computer and a printer is a report. Proof via
> reductio ad absurdum that you're an idiot.
>
> >I DISAGREE WITH YOU. Databases aren't unnecessarily 'complex'.
> >Databases don't need IT. Support Infrastructure-- Warning
> >Mechanisms... Just because you had an email fail once; is it the
> >databases fault?
> ...
>
> More manufactured BS. When did I claim any e-mail failure? I don't see
> the point to e-mail notification for PROPERLY CONCEIVED spreadsheet
> models. To make this clear, I believe spreadsheet models should be
> interactive. Spreadsheets are poor platforms for writing complex
> systems that would be run unattended. Even for models in which the
> unattended runtime would just be very long recalc, if spreadsheet
> models take more than 30 seconds to recalc, they shouldn't be
> implemented as spreadsheets.
>
> If you're right that databases aren't unnecessarily complex, wouldn't
> your time be better spent showing poor benighted Excel users how to
> solve their problems using databases? That is, if your goal were
> convincing Excel users to switch to databases. There have been annoying
> Perl solutions in many other languages' newsgroups over the years, so
> off-topic solutions have a USENET tradition even if they are contrary
> to proper netiquette. 'Course that'd assume you COULD provide any sort
> of solution to any of the questions posed in this ng. That's unproven.

[email protected] 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 spreadsheet
>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 spreadsheet 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.

I have never once reccomend the usage of MDB files anywhere.

your access folk don't know what the hell they're doing.

anyone using mdb in 2006 is out of date; just like anyone using xls in
2006 is out of date.

it is all about this technology called 'Access Data Projects'

they are the best IDE anywhere in the world-- for designing stored
procedures and views.

sql server management studio has some things on it; but it's still too
close ot call in my book.

I have never ever had an access data project that isn't lightning fast.


it keeps all the tables and views, and sprocs in one place.
a) version control is a lot easier; since you're not copying
client-side queries around
b) stronger query engine
c) parameterization
d) user defined functions
e) triggers

i think that it's an awesome friggin stack.

i mean-- it's unbeatable anywhere.

data entry forms; reports-- it's 10,000 times more powerful than xls.

im sorry you're too close minded to use modern tools.

xls is for babies.

i've got a better excel than you do; i've got better pivotTables than
you do.

give up kids




greaseman wrote:
> And your point is, besides the one on your head?
>
> This is apples and oranges, since Excel is a spreadsheet-type
> application and Access is a database application, and besides that, WHO
> CARES what you think?
>
> ".....sub-second response times against billions of records. " Really?
> How? I've worked in companies, large and small, where tons of records
> have crippled Access, as well as having several users hitting a
> database at the same time has also crippled Access.
>
> Perhaps you do know both Excel and Access, but most of your responses
> and musings in this forum are a bit simpleton and extremely prejudiced.
> You sound like, "Nyaaaa, nyaaaa, I can do this better than you can!"
> That is only because as I said earlier, one is oriented toward
> spreadsheets and one is oriented toward database processing.
>
> If you don't care for Excel, then don't use it and please find another
> newsgroup / forum to harass.
>
>
> --
> greaseman
> ------------------------------------------------------------------------
> greaseman's Profile: http://www.excelforum.com/member.php...o&userid=28808
> View this thread: http://www.excelforum.com/showthread...hreadid=544465

[email protected] wrote...
>I have never once reccomend the usage of MDB files anywhere.
....

That's true. [Fair is fair - you've been almost as strident against MDB
files.]

However that undercuts your arguments in favor of databases. Few
business users outside IT departments have permissions to do anything
more than read company databases. The only database software SOME of
them may have is Access. They won't have MSDE installed, and they won't
have any Office product CDs with which to install it, and they likely
have company technology policies that explicitly forbid them to
download and install 'unapproved' software.

So if you want all these Excel users to switch to databases, Access
*AND* MDB are necessary stepping stones along the path. So you better
get used to giving MDB answers if you want to win any converts.

Aaron - I hope you'll let me jump in here with an honest question about a
repetitive action I perform using Word and Excel files and VBA. For the
record, I'm a self-taught (more like NG taught!) VBA newbie, having started
this about 2 1/2 years ago. I used Excel rather than Access because I was
basically familiar with Excel, and know almost nothing about Access. (I
thought I was doing great once to create two tables and link both to the
same query!) Also, more of the users here are familiar with Excel and
aren't afraid of spreadsheets - very few would know what to do with an
Access file. But if this project can be better done using Access, then I'd
honestly like to know where to start learning.

We have data in a dinosaur-age database written in Pascal. Don't say we
need to update - we all know it, just as surely as we know it's not going to
change until it crashes hard one Monday morning! If I ask for a "dump" of
all the reports connected with a certain project, I get one huge continuous
text file. I have macros in Word that split this text file into individual
reports and saves them as Word docs. The macros also scan through each
individual report to pull off some 20 data points and writes these to an
Excel file. The Excel file also contains macros which allow the user to
text search the spreadsheet, text search each and all report files, and
retrieve for viewing any report file by selecting the report number on the
spreadsheet. A single folder containing all the report files and the Excel
workbook is burned to a CD and distributed to some users, and posted to a
network location for others.

My experience with Access is that the user isn't ever supposed to see the
tables. Also, I would have no idea how to create the search macros. With
Excel, the user gets to see all the data, and sort and filter as desired.
With the help of the NG MVPs, writing the Excel VBA for the search codes was
do-able.

Am I missing a whole world of distributable apps that would be "bigger,
better, faster, more"?

Ed

i disagree.

contracts are simply printed reports.

if you can't represent the logic inside a database; then you need to
find someone that can.

databases are the most flexible; most wonderful things anywhere.
because you don't need to make a duplicate copy of your data in order
to sort it in different directions-- for starters

it's all about reusing the business logic; and excel doesn't do this.

you say 'no sane company would automate contracts'

what about a sales receipt?

> Companies that don't keep records for all open contracts deserve the
> headaches that causes. Document retention is independent of Excel. As
> far as I care, put the XLS files into the databases as blobs. I've said
> before that databases handle storage tasks well.


this isn't an efficient way to do things.

a) you can't LEVERAGE THE NUMBERS; you can only search through the text
b) XML isn't going to make it better; it's going to make it worse
c) when you NEED the numbers, you pull up the text and then print it
out and then copy it into your spreadsheets.


for the record; i replaced a couple document management; mainframe
driven systems with a much simpler combination of sharepoint and
access.

so instead of having a server that is 20 years old; and a couple
dedicated admins just for that one mainframe-- the documents were self
feeding from a nice sharp web interface.

and i used Access for ETL.
yep that's right-- i used the world's most popular desktop database
system-- in order to push and pull and crunch data.

i just think that is ridiculous harlan.

Databases are SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO much sexier than
simple document repositories.

I mean seriously here.

about the whole 2-column thing; no -- i didn't realize you could pick a
named range and then do that.

I wasn't talking about a simple FIND like that.
and that 2-column thing; can you have a named range that consists of
columns F and M?

what if the columns aren't right next to each other; let me guess-- you
make a copy of the workbook; where these columns are right next to each
other and then you do it that way.

lol.. another copy of the data.. that just cracks me up.


SQL is just 10,000 times more powerful than your baby spreadsheet
solutions.

just because you have some functions that you think are the best thing
since sliced bread-- that doens't mean it's not easy to add these to
SQL.

and when you add them to SQL; your users don't get prompted about 'this
document has macros do you want to trust these macros'

that's laughable to me.








Harlan Grove wrote:
> [email protected] wrote...
> >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.
> ...
>
> It's not the business logic that matters. It's any adverse rulings in
> contract law that affect existing wording so require changes in wording
> or more precise definitions of terms. To expand upon earlier comments,
> when the number of particular contracts exceeds the average dollar
> value covered under such contracts by a decimal order of magnitude or
> more, it's usually safe to use some form of automation. When the
> reverse it true, the average dollar value of contracts exceeds the
> number of such contracts by a few decimal orders of magnitude, much
> greater care needs to go into writing each contract. There are no
> cookie-cutter solutions to generating such contracts, and business
> rules and what nonlawyers might consider logic have little to do with
> what makes sense legally.
>
> No rational company would attempt to automate producing contracts
> covering high monetary values.
>
> >oh what percentage rate; and what were the terms for contract
> >XZC98989-3 again?
> ...
>
> Common contract terms are a separate issue. To the extent there's
> uniformity, the terms are entered into company databases, after the
> fact. And scanned images of all contracts also go into the databases.
> But contracts aren't generated from databases.
>
> >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??
> ...
>
> Companies that don't keep records for all open contracts deserve the
> headaches that causes. Document retention is independent of Excel. As
> far as I care, put the XLS files into the databases as blobs. I've said
> before that databases handle storage tasks well.
>
> >you can't tell excel to 'search through 2 columns'
> >it's either one column or the whole workbook.
> ...
>
> Select the 2 cols and search? You don't realize that if you select a
> range first, Excel will only search through that range. Back of your
> hand, eh?

Access CAN send emails without using VBA.

it is called Macros.

VBA = Modules in Access.

Macros are all multiple-choice; send this report to these 4 addresses;
then print out these 4 reports; and then run this batch file and then
print 2 more reports; and then copy these files from here to here.

all without a DROP of code.

-Aaron


Harlan Grove wrote:
> [email protected] 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 spreadsheet
> >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 spreadsheet 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.

[email protected] wrote...
....
>but newbies shouldn't have to do that since ADP has such a nice
>interface for writing sprocs and views.
....

But if the average business user can't create tables or views or modify
anything in SQL Server because they lack the necessary
permissions/rights, how would ADP help them?

>i wish i could spend more time teaching people Accesss.
....

If you spent less time whining about Excel . . .

>Excel 2007 has some really really exciting technologies.. the ability
>to import olap data as either a table or a pivotTable-- that's going to
>revolutionize the way that we do business.
....

Not really. Aside from some reports (I didn't make 'em, and I' not
responsible for 'em), none of the spreadsheet models in widespread use
where I work involve pivot tables. Pivot tables may have their uses in
reporting, but much less so in analysis.

>And all you need is
>
>a) SQL Server Standard Edition
>b) office license.
....

And if your company's databases are all in Oracle or DB2 or (who knows)
mySQL? And you need to set up the OLAP cubes, but I'll stipulate that
may not be difficult if there's someone who knows how to do it. All I
can say is that there are lots of companies either without (a) or who
don't provide most users with access to it.

[email protected] wrote...
>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.
....

It's not the business logic that matters. It's any adverse rulings in
contract law that affect existing wording so require changes in wording
or more precise definitions of terms. To expand upon earlier comments,
when the number of particular contracts exceeds the average dollar
value covered under such contracts by a decimal order of magnitude or
more, it's usually safe to use some form of automation. When the
reverse it true, the average dollar value of contracts exceeds the
number of such contracts by a few decimal orders of magnitude, much
greater care needs to go into writing each contract. There are no
cookie-cutter solutions to generating such contracts, and business
rules and what nonlawyers might consider logic have little to do with
what makes sense legally.

No rational company would attempt to automate producing contracts
covering high monetary values.

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

Common contract terms are a separate issue. To the extent there's
uniformity, the terms are entered into company databases, after the
fact. And scanned images of all contracts also go into the databases.
But contracts aren't generated from databases.

>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??
....

Companies that don't keep records for all open contracts deserve the
headaches that causes. Document retention is independent of Excel. As
far as I care, put the XLS files into the databases as blobs. I've said
before that databases handle storage tasks well.

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

Select the 2 cols and search? You don't realize that if you select a
range first, Excel will only search through that range. Back of your
hand, eh?

[email protected] wrote...
>Access CAN send emails without using VBA.
>
>it is called Macros.
....

You mean SendObject? It does the same as following a mailto: url, and
at least with Lotus Notes as e-mail client it requires a following
SendKeys macro action to send the e-mail. I'll grant that Access macros
provide SendKeys and that Excel provides no equivalent to Access
macros, but it's not all that difficult to write a VBA macro to do the
same thing, follow a mailto: url and run SendKeys to sent the necessary
keystrokes to the Notes e-mail client to send the e-mail.

>all without a DROP of code.

Which is appropriate in an application that's intended to be used to
perform unattended tasks. But as soon as you need logic, e.g., run this
query and IF it produces a nonempty result (at least one record) print
that report, you need code, no?

Excel, OTOH, isn't meant for unattended operation (no more than Word
is), so a similar facility wouldn't have been as valuable.

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 spreadsheet.

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:
> [email protected] 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 spreadsheet
> >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 spreadsheet 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.

nope; you don't need code

if this and this and this and this then this then this then this then
this

else this

ALL WITHOUT A DROP OF CODE


Harlan Grove wrote:
> [email protected] wrote...
> >Access CAN send emails without using VBA.
> >
> >it is called Macros.
> ...
>
> You mean SendObject? It does the same as following a mailto: url, and
> at least with Lotus Notes as e-mail client it requires a following
> SendKeys macro action to send the e-mail. I'll grant that Access macros
> provide SendKeys and that Excel provides no equivalent to Access
> macros, but it's not all that difficult to write a VBA macro to do the
> same thing, follow a mailto: url and run SendKeys to sent the necessary
> keystrokes to the Notes e-mail client to send the e-mail.
>
> >all without a DROP of code.
>
> Which is appropriate in an application that's intended to be used to
> perform unattended tasks. But as soon as you need logic, e.g., run this
> query and IF it produces a nonempty result (at least one record) print
> that report, you need code, no?
>
> Excel, OTOH, isn't meant for unattended operation (no more than Word
> is), so a similar facility wouldn't have been as valuable.

I don't believe that keeping users out of tables should be a
requirement.

you don't keep users out of worksheets; why the reservation on tables?

i would import it to a database and then write simple queries to find
the text that you are looking for.

i have a solution right now that scans 20gb of text file in near
sub-second response times.

i catalog a couple thousand log files and look for certain strings..
then i have an olap cube that reports the presence of thest 'events'

i would honestly need a ton more information to help more; paste a
couple of lines of your log files and i would be glad to help!!

-Aaron




Ed wrote:
> Aaron - I hope you'll let me jump in here with an honest question about a
> repetitive action I perform using Word and Excel files and VBA. For the
> record, I'm a self-taught (more like NG taught!) VBA newbie, having started
> this about 2 1/2 years ago. I used Excel rather than Access because I was
> basically familiar with Excel, and know almost nothing about Access. (I
> thought I was doing great once to create two tables and link both to the
> same query!) Also, more of the users here are familiar with Excel and
> aren't afraid of spreadsheets - very few would know what to do with an
> Access file. But if this project can be better done using Access, then I'd
> honestly like to know where to start learning.
>
> We have data in a dinosaur-age database written in Pascal. Don't say we
> need to update - we all know it, just as surely as we know it's not going to
> change until it crashes hard one Monday morning! If I ask for a "dump" of
> all the reports connected with a certain project, I get one huge continuous
> text file. I have macros in Word that split this text file into individual
> reports and saves them as Word docs. The macros also scan through each
> individual report to pull off some 20 data points and writes these to an
> Excel file. The Excel file also contains macros which allow the user to
> text search the spreadsheet, text search each and all report files, and
> retrieve for viewing any report file by selecting the report number on the
> spreadsheet. A single folder containing all the report files and the Excel
> workbook is burned to a CD and distributed to some users, and posted to a
> network location for others.
>
> My experience with Access is that the user isn't ever supposed to see the
> tables. Also, I would have no idea how to create the search macros. With
> Excel, the user gets to see all the data, and sort and filter as desired.
> With the help of the NG MVPs, writing the Excel VBA for the search codes was
> do-able.
>
> Am I missing a whole world of distributable apps that would be "bigger,
> better, faster, more"?
>
> Ed

MDB are a useful learning tool

I used them for several years before moving to SQL.

but newbies shouldn't have to do that since ADP has such a nice
interface for writing sprocs and views.

and the training resources that are out there for SQL vs the training
resources for MDB?

it's possible to find any of hundreds of books; mdb doesn't have 50
books written about it

I want to help people to see the light; i'm sorry that I'm agro
sometimes.
it's just frustrating.

i wish i could spend more time teaching people Accesss.

I wish that I had gotten the project manager job at Microsoft; where I
should be working right now.

A lot of things to wish and regret.

But when all is said and done; i can write some really exciting
applications with really exciting performance-- against thousands,
millions of records

and i wish that i could just sprinkle my magic fairy dust and let you
guys see the light.


i just-- i mean.. everything i build; you can right-click SORT on it.
it's much cleaner than any other solutions out there.

right-click filter, right-click sort-- it's a very intuitive interface.

i can't wait for the next version.

Excel 2007 has some really really exciting technologies.. the ability
to import olap data as either a table or a pivotTable-- that's going to
revolutionize the way that we do business.

we've got 500-odd cubes around here; and it's a lot of fun.

We've got the most exciting pivotTables anywhere.

but it has nothing to do with excel.

it's all web-based; it's a lot more centralized than a bunch of
spreadsheets.. we keep all our report definitions in a single table..
it's each to share reports with others; copy reports; duplicate
reports; change a couple of fields..

it's just the most beautiful web-based pivotTable solution ever.

it just seems like it blows the pants off of excel pivotTables.

a) you can collapse dimensions; so that you can put manager and
employee in one dimension; allowing people to double click on a manager
in order to view the employee level..
b) performance is much better in OWC than excel
c) we keep all our reports in one place-- instead of a few thousand
spreadsheets (we literally produce 20,000 pivotTable reports off of
these olap cubes)
d) if we change something; it's real simple to loop through all the
reports; find out which ones are broken and fix them. i mean-- drag and
drop
e) it allows you to make custom calculations; using simple expressions
or complex MDX (100 times more powerful than SQL language-- it's
multi-dimensional; it's the language behind pivotTables)

i just think that it's the most beautiful technology anywhere.

it carries a lot of weight; and we've got a lot of excited excel users.

and i just mean-- the difference between having 10,000 spreadsheets and
10,000 report definitions?

all we do is have a simple XML report definition; people create these
by dragging and dropping fields in a web-based pivotTable format.

and we can have triggers-- an audit trail-- to these report defs.

and we can associate notes to these; and allow other people to blog on
these reports (all it is is a couple of fields in a database)

I just wish i could demonstrate to you guys how exciting this
technology is.

And all you need is

a) SQL Server Standard Edition
b) office license.

you dont need Access anywhere to do any of this.

but Access is how you get your data organized; move it to SQL Server
and presto-chango-- you've got a tool that can answer hundreds of
questions with very exciting levels of performance.

i mean.. drag and drop; it's 100 times faster than normal excel
pivotTables.





-Aaron


Harlan Grove wrote:
> [email protected] wrote...
> >I have never once reccomend the usage of MDB files anywhere.
> ...
>
> That's true. [Fair is fair - you've been almost as strident against MDB
> files.]
>
> However that undercuts your arguments in favor of databases. Few
> business users outside IT departments have permissions to do anything
> more than read company databases. The only database software SOME of
> them may have is Access. They won't have MSDE installed, and they won't
> have any Office product CDs with which to install it, and they likely
> have company technology policies that explicitly forbid them to
> download and install 'unapproved' software.
>
> So if you want all these Excel users to switch to databases, Access
> *AND* MDB are necessary stepping stones along the path. So you better
> get used to giving MDB answers if you want to win any converts.

>I don't believe that keeping users out of tables should be a
> requirement.
>
> you don't keep users out of worksheets; why the reservation on tables?

I can't say for sure, but I think the idea was that if you have queries
built on your tables and the user (always presented at the lower end of the
intelligence bell curve) changed the wrong thing, he could break everything.

> i would import it to a database and then write simple queries to find
> the text that you are looking for.
> i catalog a couple thousand log files and look for certain strings..
> then i have an olap cube that reports the presence of thest 'events'

I understand the words "database", "queries", and "strings" in _my_ world,
but I'm not sure I understand what you're trying to present to me when ~you~
use them.

> i would honestly need a ton more information to help more; paste a
> couple of lines of your log files and i would be glad to help!!

Information maybe I can do; pasting any of this stuff could cost me my job
(and a whole lot more!).

The biggest issues are:
(a) Any user needs to be able to request a database "dump" for his/her
project (this will give the user one or more text files containing all the
separate reports as one continuous file - actually where each line is output
as a separate paragraph) and run this app to split the dump file(s) into the
separate report files, which are saved into a created folder.
(b) The app needs to scan each separate file as it is created to pull out
data points which are written into a spreadsheet / table.
(c) This app must use only Word, Excel, and / or Access (we don't have
permission to use any other "non-approved" applications), and must run from
the user's desktop or laptop.
(d) The user must be able to run queries / macros which:
>> compare this week's table to last week's to find changes
>> text search the entire table
>> text search all report files in the folder
>> sift and sort the table data as required to create tables to paste into
>> Word

At the largest volume, I had 20 separate dumps which, when split, yielded
over 14,000 separate Word files, The process took about 10 minutes to split
out all the reports, write data to the Excel file, and then update several
hundred hyperlinks to summary reports which had to be matched to the same
report number which was now in a different position in the Excel worksheet
(because new information wasn't necessarily added on at the end). But it
was distributable to any person to run on their machine, both the main
routines and all the search functions.

And what would be my learning curve to know and understand enough of this to
intelligently maintain and modify this app?

Ed

<[email protected]> wrote in message
news:[email protected]...
>I don't believe that keeping users out of tables should be a
> requirement.
>
> you don't keep users out of worksheets; why the reservation on tables?
>
> i would import it to a database and then write simple queries to find
> the text that you are looking for.
>
> i have a solution right now that scans 20gb of text file in near
> sub-second response times.
>
> i catalog a couple thousand log files and look for certain strings..
> then i have an olap cube that reports the presence of thest 'events'
>
> i would honestly need a ton more information to help more; paste a
> couple of lines of your log files and i would be glad to help!!
>
> -Aaron
>
>
>
>
> Ed wrote:
>> Aaron - I hope you'll let me jump in here with an honest question about a
>> repetitive action I perform using Word and Excel files and VBA. For the
>> record, I'm a self-taught (more like NG taught!) VBA newbie, having
>> started
>> this about 2 1/2 years ago. I used Excel rather than Access because I
>> was
>> basically familiar with Excel, and know almost nothing about Access. (I
>> thought I was doing great once to create two tables and link both to the
>> same query!) Also, more of the users here are familiar with Excel and
>> aren't afraid of spreadsheets - very few would know what to do with an
>> Access file. But if this project can be better done using Access, then
>> I'd
>> honestly like to know where to start learning.
>>
>> We have data in a dinosaur-age database written in Pascal. Don't say we
>> need to update - we all know it, just as surely as we know it's not going
>> to
>> change until it crashes hard one Monday morning! If I ask for a "dump"
>> of
>> all the reports connected with a certain project, I get one huge
>> continuous
>> text file. I have macros in Word that split this text file into
>> individual
>> reports and saves them as Word docs. The macros also scan through each
>> individual report to pull off some 20 data points and writes these to an
>> Excel file. The Excel file also contains macros which allow the user to
>> text search the spreadsheet, text search each and all report files, and
>> retrieve for viewing any report file by selecting the report number on
>> the
>> spreadsheet. A single folder containing all the report files and the
>> Excel
>> workbook is burned to a CD and distributed to some users, and posted to a
>> network location for others.
>>
>> My experience with Access is that the user isn't ever supposed to see the
>> tables. Also, I would have no idea how to create the search macros.
>> With
>> Excel, the user gets to see all the data, and sort and filter as desired.
>> With the help of the NG MVPs, writing the Excel VBA for the search codes
>> was
>> do-able.
>>
>> Am I missing a whole world of distributable apps that would be "bigger,
>> better, faster, more"?
>>
>> Ed
>

[email protected] wrote...
>a) if you keep your data in different databae; i could give a rats ***.
> we can use ODBC for anything we need.

So no SQL Server but DB2. And what OLAP facilities there are are
provided by Essbase. And that configuration still allows for full use
of ADP and OLAP just as you'd use them with SQL Server? I honestly
don't know.

>b) when you sit around and wonder 'what if people dont have permissions
>to write to sql'
> i just think that you miss the point.
>
>Do you know what NTFS is?
>
>NTFS is going to be replaced by.. uh.. get this-- SQL Server
>this is called 'WinFS' and it has been in the works for 15 years in
>redmond.

And it'll still depend on who gets permissions/rights to what, but good
ol' Microsoft OS's will likely default to everyone has unlimited
permissions/rights.

Database as file system ain't new. It was one of the key features of
BeOS.

>it has previously been called 'Cairo'

I think you mean Longhorn. Cairo became Windows 2000, which predated
talk of WinFS by years.

>On your desktop-- you'll be running SQL Server behind the scenes.
>this means that you can toss around sql server databases just like
>they're documents.

Yup, database as storage subsystem. And hierarchical organization using
parent fields in the WinFS database. In case you can't tell, I'm not
sold on the benefits of WinFS.

>it isn't risky to allow end users to create databases. create tables;
>create views and sprocs.
....

Maybe not, but most IT shops give most users minimal (read only) if any
access to company databases. You may really, really believe it should
be otherwise, but all your wishing means squat.

>WinFS-- when it ever shows up-- it SHOULD **SHOULD** allow all end
>users to have their own playground for SQL Server.
....

You're confusing database as storage subsystem for WinFS with a DBMS
with which users can create tables, views, forms, reports, etc. WinFS
is more likely to be a database runtime, like Access runtime, that
provides database functionality for packaged systems (in the case of
WinFS, the OS's file system), but it's unlikely to provide users the
ability to create their own databases. I could be wrong.

>you go to open the MDF 'file' and you've got a SQL Server database;
>just as if it were a document.

MDF? That's SQL Server's database file format? How does one create MDF
files if one uses Oracle, DB2 or mySQL?

>but even today-- in more rational terms-- i reccomend that every person
>in the world have a SQL Server 2005 Express or MSDE installed on their
>desktop.
....

You need to convince IT departments. Good luck!

>I'm just blown away-- the free enterprise-level database offerings..
>IBM and Oracle finally woke up to the reality that MS was kicking their
>*** in the db market..
....

The really big databases still run on mainframes, e.g., banks with
millions of transactions per week if not per day. And trying to find
DBMS market share information on the web isn't easy. But if Microsoft
were so successful with SQL Server, how can Oracle have such a high
market capitalization. Another case of Aaron is right and the rest of
humanity wrong?

>Oracle won't ever be a threat to Microsoft because Oracle is a
>one-trick pony.
>they don't have an office suite.
....

They don't need one apparently.

>I just dont' like the idea of having mixed environments... having 3 or
>4 different flavors of databases-- it's not the most efficient way to
>do things.
....

That's likely true. However, companies with decades' worth of mainframe
data and serviceable mainframe systems aren't going to drop them just
for the heck of it. There will be heterogenous environments as long as
there's heterogenous hardware.

>but the bottom line is that excel is inherently a single-user
>interface; a single-user database.

Single-user interface? Correct. Single-user database? Nope. It's not a
database. It could be misused as a database. So could Word. You keep
trying to force-fit it into an inappropriate category, making it seem
like you can't understand anything that isn't a database - probably an
accurate assessment of your 'thought' process.

Just for the record, way back in June of 2005, someone else wrote:

>Then you're being an even more obtuse moron that I had already figured.

Guess I wasn't the only one thinking this Troll was a moron.