Thread: why>?

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

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

-Aaron

aaron.kempf@gmail.com 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?

aaron.kempf@gmail.com 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

aaron.kempf@gmail.com 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

<aaron.kempf@gmail.com> wrote in message
news:1148420657.220936.30000@i40g2000cwc.googlegroups.com...
>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

<aaron.kempf@gmail.com> wrote in message
news:1148332296.581383.267130@j33g2000cwa.googlegroups.com...
> 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

<aaron.kempf@gmail.com> wrote in message
news:1148332296.581383.267130@j33g2000cwa.googlegroups.com...
> 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.

aaron.kempf@gmail.com 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.