(e-mail address removed) wrote...
yes, i do believe that any function that you REALLLLLLLLLLLLLY need can
be easily recreated by UDFs. If they can't that is where you can have
a programmer in to help you with your 'super-duper hard math'--
And it'd be completely pointless. I already have software that works.
It's called Excel. Other than in your delusions, why would it make
sense to reinvent the wheel?
Oh, that's right, in order to make Access do things Excel does better.
Clueless, clueless, clueless!
god you are just a flaming idiot.. and AOL user.. and an Excel FAG
Nothing like a good ad homenim attack when you can't make a reasoned
argument.
you CAN have security and unrestricted access.
you can have security in one place and unrestricted access in others.
Each user creates all the tables they want and all other users have
read-only access to it? Or all users can specify all the table layouts
they want, and all users can have read-write but not redesign access to
it? Who gets to specify any relations between John's XYZ table and
Jane's ABC view? Both John and Jane? What's to prevent either from
creating problems with other relations? For that matter, who gets to
decide what records could be deleted, or do you believe in infinite
disk storage? If specific individuals have more rights to some tables
than others, how do you manage succession, e.g., when John quits, who
assumes his rights to his tables? And that does even get to the BIG
RISKS when giving CREATE TABLE rights to naive users - other than
system crashes, what's to prevent them from inadertently creating
unindexed multiple terabyte flat files then running queries against
them?
where you build SPROCS and VIEWS-- you can have whatever perms you
want.
It's just much better than KEEPING YOUR SHORTS AROUND YOUR ANKLES AND
LETTING PEOPLE 'FUDGE NUMBERS' WHENEVER THEY WANT.
People can fudge numbers in databases. Unless absolutely *ALL* queries
are stored and *ALL* temporary tables are crossreferenced against the
stored queries, it soon becomes impossible to verify anything in
databases.
If it were so easy just to give all users basically unrestricted access
to database 'workspaces', don't you think it would have become a wider
spread practice than it is?
These functions are all easily and freely available on the internet--
if you really MUST have this 'complex math'-- gag me with a spoon.
They're not usually available in a form that could be dropped into a
VBA module and used without modification. There's a lot of cookbook C,
Java, Perl and Python code on the internet but not as much VB[A]. Just
try to find linear regression functions in VB[A] that handle
colinearity well. Or regular expression engines.
The point of the matter is that SQL Server is EXTENSIBLE. Where as
Excel is just a dead-end street.
If by extensible you mean able to employ add-on software modules, guess
what? Excel is also extensible. More easily so since Excel .XLA add-ins
can be developed in Excel itself. No doubt you'd have no idea how to do
this, but that doesn't mean it isn't possible.
If you mean multiple machines can be used to complete a single logical
task, that's nice. Excel isn't intended to be extensible in that way.
Making a software development platform extensible in that way
necessarily involves imposing some rigidity to provide the interfaces
needed to accomplish such extensibility. Excel is intended to be
flexible. That flexibility prevents scaling, but it allows other
functionality that would be difficult to impossible using centralized
databases (such as providing hundreds of mortgage brokers amortization
table templates they could use on disconnected laptops). You don't
understand that there are times when it's a GOOD THING to have
thousands of copies of more or less the same thing.
Excel is a TOTAL waste of time.. and you guys aren't worth JACK SHIT in
the marketplace.
Gosh, you'd have thought someone like our managers would have realized
that by now.
You won't understand this, but most of the rest of use are paid for
specific knowledge or abilities that aren't directly related to any
piece of software. Lawyers, accountants, financial analysts,
statisticians, market analysts aren't hire or paid for whether they
know Excel or Access or SQL server, they're hired and paid for what
they know about law, accounting, etc. They use software as tools to to
their jobs, but the software isn't the central focus of their jobs.
You, on the other hand, presumably work exclusively with software, and
the central focus of your job is the software. That skews your
perspective.
There'll always be very highly paid professionals who know squat about
databases, and they'll hire people who hire people who hire people who
hire grunts like you to clean out the IT sewer pipes.
i just think that it's fucking hilarious.. that you guys sit there; you
insulate yourself from the reality that is todays' marketplace.. you
guys sit there and think 'oh, as long as im REALLY GOOD WITH EXCEL than
Since few of us are hired specifically to program in Excel or anything
else but are hired for our subject knowledge, I think we're pretty
safe.
If we were like you and were just churning out reports, we might need
to worry about whether we're up to date on databases. Mercifully, few
of us are like you.
Just like septic tank cleaners and practical nurses to empty bedpans.
WHAT IS YOUR RECCOMENDATION FOR THE OP?
Oh, now we're back to the original topic, are we?
Reread the OP's follow up, from which: "Let's assume that we must use
EXCEL[...]" Gee, what a radical concept in an Excel newsgroup!
To be honest, I had nothing to add to Bob Phillips's responses. The
OP's tasks is likely to be better suited to databases. My responses to
you were due to your overly broad assertions about what Access can do.
So far you've failed to show that Access or MSDE or SQL Server or
Analytical Services can do several things I've shown can be done
without much fuss or bother in Excel. Sifting out the bluster in your
responses, it's impossible to tell whether you can handle even any
database task more complicated than calculating a check register.
WHAT ARE YOU GOING TO DO WHEN YOU HAVE THIS STUPID EXCEL REPORT WITH
40K ROWS AND YOUR COMPANY _GROWS_ AND NOW YOU NEED 70K ROWS?
No one reads reports with 40K rows. At 60 lines per page, 40K rows
means over 666 pages (the number of the beast report). Some mainframe
reports generate +1,000 page printouts, but they're generally used like
phone books or dictionaries. Things like that are best left on
centralized machines. But when it comes to distilling those reports,
it's open question what the best tool would be. Often, but not always,
it'd be a database *IF* the source data could be accessed via queries.
I mean seriously-- what is your resolution, mr smarty pants?
Use a database if you need a database. However, databases aren't useful
for every tasks that benefit from computer processing.
my resoultion is to build SCALABLE APPS that have BETTER REPORTING than
that piece of crap, unmanageable SPREADSHEET DISEASE.
Fine if you're generating reports based on data from central data
stores.
I really do want to know 'what math do you do that is so hard that i
cant do it in a database'-- do you still think that all the ATMs of the
world use EXCEL?
ATM math is SIMPLE, much like your thought processes are simplistic.
All ATMs do is add and subtract. Not all that difficult.
Do you believe all math is that simple?
Do you really think that your way is the right way for small businesses?
For bookkeeping? I wouldn't recommend Excel, but I wouldn't recommend
Access either. Quicken Books would make more sense to me. And just out
of curiousity, is there tax prep software that interfaces with Access?
For customer management or inventory control, Access may be useful, but
it'd be a better idea to buy prepackaged single purpose software in
order to avoid wasting time programming rather than selling to or
servicing existing customers and extending the customer base.
Do you really think that your way is the right way for medium businesses?
For repeating tasks that use existing data, databases would be the best
tools to use.
On the other hand, if you mean generating quotes for long-term
projects, I'd pull some data from databases, but I'd build the quote in
Excel in order to perform what-if analysis to identify the key risks.
Do you really think that your way is the right way for large businesses?
Same reply as for medium businesses. For repetitive, easily automated
tasks, use databases. For more customized analysis to be performed by
professionals, give them the tools *THEY* ask to use. If they ask for
Excel, give 'em Excel. If they ask for Access, give 'em Access. If they
ask for MatLab, give 'em MatLab. But don't screw around giving everyone
Access and tell them to write their own udfs for everything Access
doesn't provide.
I give you a resounding, NO, NO AND NO.
Since I never said to use Excel for everything, this is a red herring.
I said use the best tool for the task. Access/MSDE/SQL Server isn't the
best tool for every task.
Small businesses shouldn't need to keep a spreadsheet dork around to
get their job done.
....
And if the single proprietor is the spreadsheet user, s/he should fire
him/herself?
I never said that ALL USERS should be able to edit ALL DATA.
Why can't I put words into your mouth like you put them in mine?
I'm saying that having a hundred different data islands is a WASTE OF
TIME.
If everyone needs that data, true. Not all data is needed by all users.
All needed data isn't always already available from centralized
databases.
you can have a solution that scales; that works reliably.. you dont
need to run out and buy sharepoint-- which is what you really need to
do if you have a hundred spreadsheets.
Who uses Sharepoint?
I'm not saying that these worthless 'statpack' functions are worthless.
I'm just saying that 90% of the people out there dont need to use them
on a daily basis. And for the last 10% of you power users (as if a
single spreadsheet dork has ever been POWERFUL) then you can run out
and find the functions with google and put them on ADP/MSDE
Clueless.
Why should I want to reinvent the wheel? Most of the free or open
source functions exist wrapped in interfaces specific to other systems
and aren't written in VB. There are commercial libraries, but they
require interface functions. And why should I want to pay for
functionality I already have?
As for '90% of users . . .', most users don't try to misuse
spreadsheets as databases. And only a small fraction of spreadsheet
users generate any reports at all, whether in Excel or Access or
anything else.
SQL Server has taken over the fucking world.
Odd, you'd think Oracle and IBM would be baknrupt if this were true.
