The best elegant solution to override 65k rows limit in a sheet

[Harlan Grove]

(e-mail address removed) wrote...
....

Atms dont use Excel. Amazon.com doesnt run on Excel.
Why do you think that your math is so hard?

ATMs add and subtract. Not very difficult. Amazon.com's web interface
doesn't run on Excel, but I wonder what their financial reporting
deparment uses to generate the figures in their quarterly and annual
reports?

So I'll conclude from this you have no clue how to respond to my
challenge in

http://groups-beta.google.com/group/microsoft.public.excel/msg/5fb6791475f21435?dmode=source&hl=en

Excel-- Word-- decentralized documents are a PITA since you have to go
and change things in 100 differet places. It is better, easier and
more productive longterm to store your DATA in a DATABASE and if you're
reporting on DATABASES it is easier to use Crystal Reports or Access to
make reports than Excel

Excel, Word and decentralization are FLEXIBLE. They work when the
network is fubar. They allow me to work offline and bring work home on
a disk to use my home PC. They allow me to share files with people
outside my company who'd better not have access to my company's
database.

It's clear you have no clue about real world data sharing with people
outside your company.

Now *IF* one needs to generate reports, then I agree Access and other
reporting packages are usually better than Excel. Small, niggling
little points to the contrary would include people who need to generate
reports but who don't have Access or any report generation software but
do have Excel. There's also the occasional report that's nothing more
than a summary of information from hardcopy sources.

Then there are all the other Excel users who aren't getting paid to
produce reports but are getting paid to produce analyses. You wouldn't
understand that. It'd require thinking.

 

[aaron.kempf]

ALL MATH IS A SIMPLE ADD AND SUBTRACT

get off your high horse; your math isn't 'TOO HARD' for a database and
you will be roadkill if you dont expand your horizons

it's time that beancounters are held to the same standard as
developers.. thats' all you dorks do is develop Excel CRAP but you guys
dont push yourselves anywhere near as hard as us IT people

i urge you to learn Crystal or Access.

Excel was passe in 1995.

 

[Harlan Grove]

(e-mail address removed) wrote...

ALL MATH IS A SIMPLE ADD AND SUBTRACT

So needless to say you have no clue what EXP, LN and IRR functions do,
just to name 3 that do a bit more than add and subtract.

All math may reduce to arithmetic when calculating cardinal and ordinal
results, but the magic is in the algorithms, data structures and
referencing mechanisms. In databases, there's only one data structure:
tables; and there are only two referencing mechanisms: SELECT queries
with and without joins.

get off your high horse; your math isn't 'TOO HARD' for a database and
you will be roadkill if you dont expand your horizons

The calculations take place in the same CPU for Excel and Access, so
they shouldn't differ in 'hardness'.

The problem with databases is the relative inflexibility of tables as
data structures and the awkwardness of queries as the only referencing
mechanism (unless you assume the existence of tons of additional
software to which few if any non-IT business users have access).

We've already seen that you can't come up with anything better for
simple amortization tables than the queries *I* proposed in

http://groups-beta.google.com/group/microsoft.public.excel/msg/ee7524741faf6518?dmode=source&hl=en

which proves nothing more than you're clueless about how to make
amortization tables. The necessary queries are a joke compared to the
simplicity of how to do this in Excel *FROM* *SCRATCH*, to wit,

1. Define R with the periodic interest rate, N as the number of periods
over which loan payments would be made, A as the initial loan amount,
and P as =PMT(R,N,-A). Since you'd also need to specify these in a
database approach, same data entry requirements so far in Excel and
Access.

2. Enter the following column labels in A1:E1.

A1: Month Number
B1: Prior Balance
C1: Interest
D1: Principal
E1: Current Balance

3. Fill in the first record in A2:E2.

A2: 0
B2: 0
C2: 0
D2: 0
E2: =A

4. Fill in the template formulas for the second record in A3:E3.

A3: =A2+1
B3: =E2
C3: =R*B3
D3: =P-C3
E3: =B3-D3

5. Complete the table by selecting A3:E3 and filling down into A4:E362.

Real hard. Oh so much more difficult than 5 obscure SQL queries,
especially since calculating interest portions directly in Excel (prior
balance times periodic rate) is so much more difficult than calculating
the principal portion directly in Access (periodic payment divided by
one plus periodic interest rate raised to N less current month number
plus 1).

You are so clueless.

Then, just speaking for myself, since I'm having to spoon-feed you the
queries needed to perform the tasks *YOU* say are so easy to do in
databases but *YOU* have proven to be incapable of providing, looks
like I have nothing to fear from you if every company I could work for
were to ban Excel tomorrow and mandate Access use only. The difference
between us is that I know how to use the tools you claim are the only
ones anyone needs to use while you can't figure out the other tools I
use.

Who's roadkill?

Well, neither of us. I'll have a job because I'm so clever, and you'll
have a job because database grunts, like septic tank cleaners, will
always be in some demand.

 

[aaron.kempf]

yeah.. you're right i can't do exponential stuff on the database..

DIPSHIT!

I dont keep data in RANGES i keep data in TABLES

it's not about inflexibility; it is about consuming your data in
multiple places; instead of COPYING AND PASTING IT TO MULTIPLE PLACES.

Get off your high horse; your math is 3rd grade level and I can do
anything on the database side in my sleep.

unless you really think that mortgage companies use EXCEL to calculate
this stuff.. I'd STFU
Databases have been eating you guys for lunch.. it is a shame that
there are millions of Excel dorks out there.. I hope that you guys face
1/10th of the workload that database people carried..

i mean seriously.

THIS ARMY HAS TOO MANY SOLDIERS AND NOT ENOUGH TANKS

Databases = Tanks
Excel = Soldiers

Soldiers can't go over a trench; they get stopped by BB guns.

Tanks (databases) plow through your math like you woudn't believe.

 

[aaron.kempf]

and databases have a LOT more than select, for starters there is
UPDATE, DELETE, INSERT..

the WITH clause (of MDX and CTEs)

I can figure out enough about Excel to say that I'm tired of keeping my
important numbers in 300 different places.

I keep my calculations in a database; and then i can spit them out into
Excel, Crystal, ASP.. i can display numbers in 100 different formats.
10,000 different formats for christ sakes.

And you idiots are still emailign around 100mb XLS files.. I mean..
WAKE UP AND SMELL THE COFFEE; EXCEL WAS PASSE IN 1995.

 

[aaron.kempf]

database grunts.. shit

i just think that it's funny that there isn't certification for Excel
dorks.. i mean.. its obvious that you all collectively aren't smart
enough to have a little bit of standardization.

i think that there should be 10 different flavors of excel
certification; because everywhere I've gone you excel dorks dont know
what the hell you're doing

 

[Harlan Grove]

(e-mail address removed) wrote...
....

unless you really think that mortgage companies use EXCEL to calculate
this stuff.. I'd STFU

Mortgage companies probably use decades-old COBOL programs for this,
accessing data via ISM-VSAM. That's for the back office stuff. For the
point-of-sale tables mortgage brokers give their customers, YES, they
do use spreadsheets to generate sample amortization tables.

How ignorant are you?!

THIS ARMY HAS TOO MANY SOLDIERS AND NOT ENOUGH TANKS

Databases = Tanks
Excel = Soldiers

....

Your metaphor.

Used by someone with an ounce of sense, these would be US tanks against
Iraqi soldiers. Used by you, these would be soviet tanks against
Afghani soldiers. Do you know enough recent history to know the
difference?

Continuing this metaphor, tanks ain't all that useful in jungles,
mountains, amphibious operations, air drops. They're really only useful
in flat, open country without mud or with roads. Soldiers are useful
and needed everywhere.

Talk about rhetorical self-immolation. Do you ever stop to think before
writing this drivel? That begs a broader question: do you ever think?!

 

[Harlan Grove]

(e-mail address removed) wrote...

and databases have a LOT more than select, for starters there is
UPDATE, DELETE, INSERT..

*NOT* for referencing existing data they don't. These queries all
CHANGE tables, only SELECT fetches data from tables.

the WITH clause (of MDX and CTEs)

Irrelevant - again you're assuming the existence of additional
software. If I assumed a full SAS system interfaced with a SQL
database, could I then claim all SAS data step code was just part of
the database interface? Well, if I were you I guess I could, but
thinking people would have a different opinion.

 

[aaron.kempf]

listen asshole

select is about 100 times more powerful than spreadsheets.

select is a whole worksheet.. if you have 2 or 3 worksheets in excel;
you're talking about 100mb excel file lol
i mean.. storing data in one place and then pointing to it-- it is a
lot easier than pulling around all your data and emailling all your
data to your clients

databases make the world go around

it's time for you excel dorks to get up to speed. there are too many
foot soldiers and not enough tanks in this battle.

 

[Harlan Grove]

(e-mail address removed) wrote...

select is about 100 times more powerful than spreadsheets.

If you want to select data pretty much as it comes from one table or
several joined tables, perhaps. If you want to correspond values from
some field but from different records, it gets difficult very quickly.

Consider another simple example: 5 point moving averages from a table
in which the first field is observation number and the second field is
observation value. In Excel, real difficult: sort the table on
observation number in ascending order, then starting with the 5th
observation, average the first 5 values up to the current record's (5th
observation's) value, then fill that formula down for the remaining
records.

What sort of gyrations does something this simple require in a SELECT
query? Pure SQL, no assuming additional software like Analysis
Services.

i mean.. storing data in one place and then pointing to it-- it is a
lot easier than pulling around all your data and emailling all your
data to your clients

Unless one's IT department won't provide access to anyone outside the
company, in which case, oh great genius, how does one share data with
customers/clients? Hint: not by an ODBC or web database feed.

databases make the world go around

Excretion is a necessary part of living . . . and an unavoidable aspect
of your postings.

 

[aaron.kempf]

look jerk

pulling stuff from multiple tables is EASY
that is why they make temp tables, derived tables; views.. i mean..
COME ON

if i want to provide REPORTS to customers I would use the crappiest
software ever; Adobe Acrobat. I would send them a copy of the REPORT
instead of a copy of the data.

that is my big beef with Excel; it isn't designed for REPORTING but you
numnuts use it for reporting all the time

you can't export an Excel sheet into a REPORT file and email it around.
what happens when you DONT want people to change your numbers?
what happens when you DONT want to email a 100mb spreadsheet?

you guys have lost your PRIVELEGES.. Go back to school and learn
something with a future.

Databases trump spreadsheets any day of the week.


Consider another simple example: 5 point moving averages from a table
in which the first field is observation number and the second field is
observation value. In Excel, real difficult: sort the table on
observation number in ascending order, then starting with the 5th
observation, average the first 5 values up to the current record's (5th

observation's) value, then fill that formula down for the remaining
records.

1) sorting and averaging; that stuff is OBVIOUSLY easier in a database.
For starters; when you change the SORT ORDER it doesn't break your
other reports. Do you seriously propose having multiple copies of the
DATA in a spreadsheets; sorted in different order? LOL

2) starting with the 5th.. come on-- gag me with a spoon.. select top 5
as a subquery.. that is easy.

3) instead of COPYING FORMULAS all over the world; you can have ONE
FORMULA in ONE PLACE. I mean.. what happens when you change the
formula?

(hint, it is easier to change a formula in one place than in 20,000
rows on 20 different worksheets).

good luck kid.. keep up the good work..

all i know is that EXCEL IS A FUCKING DISEASE AND YOU GUYS ARE LEPERS

 

[Harlan Grove]

(e-mail address removed) wrote...

pulling stuff from multiple tables is EASY
that is why they make temp tables, derived tables; views.. i mean..
COME ON

Pulling things from *MULTIPLE* tables is easy. Pulling related
information from the *SAME* table but from different records is
*DIFFICULT*. If I'm wrong, prove it! Show us how to do it elegantly!

You've suggested how to handle moving averages a while ago. Something
like

SELECT (D1.ObsVal+D2.ObsVal+D3.ObsVal+D4.ObsVal+D5.ObsVal)/5 AS MA5PT
FROM (((D AS D1 INNER JOIN D AS D2 ON D1.ObsNum=D2.ObsNum+1)
INNER JOIN D AS D3 ON D2.ObsNum=D3.ObsNum+1)
INNER JOIN D AS D4 ON D3.ObsNum=D4.ObsNum+1)
INNER JOIN D AS D5 ON D4.ObsNum=D5.ObsNum+1;

Maybe that seems clear to you. If there were column headings in A1:B1
and the first record in A2:B2, the Excel formula to calculate this
would be

C6:
=AVERAGE(B2:B6)

Double click the fill handle after entering this formula, and it's
done.

But the real strength of flexible referencing (a la Excel) comes when
you want to vary the number of points in the moving averages. Enter the
formula

C2:
=IF(ROW()>C$1,AVERAGE(OFFSET(B2,1-C$1,0,C$1,1)),"")

and fill it down in column C. Now enter 5 to get 5-point moving
averages, 3 to get 3 point moving averages, 10 to get 10-point moving
averages, etc. You'd need different SELECT queries for each of these,
and you're more deluded than usual if you believe anyone other than
yourself would find the necessary queries anything other than tedious
and repetitious.

if i want to provide REPORTS to customers I would use the crappiest
software ever; Adobe Acrobat. I would send them a copy of the REPORT
instead of a copy of the data.

That's normal practice. It prevents later disputes or MUCHO work trying
to figure out how they derived numbers from raw data. You're just
putting your own ignorance on display again.

that is my big beef with Excel; it isn't designed for REPORTING but you
numnuts use it for reporting all the time

No, *YOU* or people *YOU* work with use it for reporting. Others may
also, but I don't.

you can't export an Excel sheet into a REPORT file and email it around.
what happens when you DONT want people to change your numbers?
what happens when you DONT want to email a 100mb spreadsheet?

You send PDF files! Simple, ain't it?!

Databases trump spreadsheets any day of the week.

For doing mindnumbingly repetitive stuff, which is all that you're
likely allowed to do, you're right.

1) sorting and averaging; that stuff is OBVIOUSLY easier in a database.
For starters; when you change the SORT ORDER it doesn't break your
other reports. Do you seriously propose having multiple copies of the
DATA in a spreadsheets; sorted in different order? LOL

Sorting is purely subjective. Some like you may prefer query predicates
like 'ORDER BY FOO ASC', others would prefer specifying columns via
dialogs. Agreed that Excel's limitation of just 3 sort columns is
absurd.

2) starting with the 5th.. come on-- gag me with a spoon.. select top 5
as a subquery.. that is easy.

You'd need to repeatedly subquery the top 5. If you have 100 records,
you have 96 5-point moving averages.

3) instead of COPYING FORMULAS all over the world; you can have ONE
FORMULA in ONE PLACE. I mean.. what happens when you change the
formula?

Except as pointed out above, you could have one Excel formula capable
of generating N-point moving averages for any positive integer N (well,
up to 65535). You need separate queries for each N in rdbms's.

(hint, it is easier to change a formula in one place than in 20,000
rows on 20 different worksheets).

Hint: if you know how to use spreadsheets well, it takes *ONE* formula
to do what it'd take thousands of different queries to do.

 

[aaron.kempf]

you're wrong.. subqueries and temp tables can do anything like that
that you need to... and it's a LOT more scalable than Excel..

you can write views and sprocs-- using drag and drop.. it is just a lot
more practical than Excel.. you keep all your data in one place; and
you dont have to email 200mb spreadsheets.. you can email around small
reports instead

or.. get this.. URLS
if you put your logic into a database then it is easy to build it as a
webpage.. so it's easy to share it between offices for example

-aaron

 

[aaron.kempf]

thousands of different queries.. i mean. shit.. like that's an actual
slam on databases??

lol

i'd rather have thousands of queries than a dozen spreadsheets.. any
day of the week.
i'd be honored to have thousands of queries.

but i could do anything in one query that you can do..
and most of the formulas are even THE SAME. So you can take your
worthless Excel knowledge and turn it into something useful.. instead
of having to recreate the wheel week in and week out; you can build it
once and then it's easy to run a report for different weeks.

in excel; you have a different version of the report every week with
different numbers..

it's just a diseased way of doing business. keeping all your logic and
all your data in a dozen different workbooks.. i mean-- that is
inefficiency at it's most dangerous form.

CRYSTAL REPORTS.. or ACCESS. Sure it might cost a little bit more for
one or two users; but Excel is just a dead end street..

100 spreadsheets can't SAVE a company.. 100 database reports CAN.

-aaron

 

[Harlan Grove]

(e-mail address removed) wrote...

you're wrong.. subqueries and temp tables can do anything like that
that you need to... and it's a LOT more scalable than Excel..

A macro assembler can do anything I want to do on a computer too, but I
know better than to use one to reinvent wheels inefficiently.

you can write views and sprocs-- using drag and drop.. it is just a lot
more practical than Excel.. you keep all your data in one place; and
you dont have to email 200mb spreadsheets.. you can email around small
reports instead

Can you write sprocs in Access that run against MDB files? Can non-IT
users with read-only access to database servers create them? Or views?

And how, exactly, would views be all that much help? If I wanted
rolling N-period averages of values in some table, I'd need a separate
view for repeated inner joins for each possible value of N. You just
don't get it that while it's possible to generate tables with records
composed of values from different records in some source table, that
particular referencing mechanism in SQL is more complicated and less
understandable than the equivalent referencing syntax in damn near all
other software. I realize you don't believe it, but there are times
arrays and explicit indexing are superior to SELECT queries on tables.

Another thing you're failing to understand is that nearly all non-IT
dept business users *LACK* developer access to their company's database
servers. On the other hand, if they have Excel at all, they can develop
in Excel.

Keeping data in one place presupposes users can *STORE* their data
centrally. Most non-IT users with some database server access can only
*LOAD* company data from central store. Their own data is stuck on
their own machines.

Your lack of perspective prevents you from understanding this.

or.. get this.. URLS
if you put your logic into a database then it is easy to build it as a
webpage.. so it's easy to share it between offices for example

If you can post anything to your company's intranet servers. Again,
most non-IT people can't.

It'd be easy enough to write an Excel workbook to pull data via
external queries, then use spreadsheet formulas to produce final
results, then e-mail the workbook. That's what most non-It people do
because that's the *ONLY* means they have to share results in a
more-or-less automated manner. Maybe some of them wouldn't know how do
this any other way, but if no other way is possible, it'd be highly
inefficient to waste time learining useless alternatives.

 

[Harlan Grove]

(e-mail address removed) wrote...

thousands of different queries.. i mean. shit.. like that's an actual
slam on databases??

lol

Running them, sure. Writing them is a whole different issue. So some
idiot actually would pay you to write

SELECT (D1.val + D2.Val) / 2 AS MA2PT
FROM D AS D1 INNER JOIN D AS D2 ON D1.key = D2.key + 1;

SELECT (D1.val + D2.Val + D3.val) / 3 AS MA3PT
FROM (D AS D1 INNER JOIN D AS D2 ON D1.key = D2.key + 1)
INNER JOIN D AS D3 ON D2.key = D3.key + 1;

SELECT (D1.val + D2.Val + D3.val + D4.val) / 4 AS MA4PT
FROM ((D AS D1 INNER JOIN D AS D2 ON D1.key = D2.key + 1)
INNER JOIN D AS D3 ON D2.key = D3.key + 1)
INNER JOIN D AS D4 ON D3.key = D4.key + 1;

....

rather than fire you for wasting time by not using Excel when it's the
more efficient tool?

i'd rather have thousands of queries than a dozen spreadsheets.. any
day of the week.
i'd be honored to have thousands of queries.

And how long would it take you to write them?

but i could do anything in one query that you can do..

OK, show hou to create an amortization table in *ONE* query.

in excel; you have a different version of the report every week with
different numbers..

No, *YOU* generate weekly reports. If that's all you're good for, you
should be using a database.

it's just a diseased way of doing business. keeping all your logic and
all your data in a dozen different workbooks.. i mean-- that is
inefficiency at it's most dangerous form.

Sometimes it is inefficient, but it's flexible. Far more users have
Excel and shared .XLS files than have database server access rights
needed to do anything more than run SELECT queries against company
data, not their own customer's data.

100 spreadsheets can't SAVE a company.. 100 database reports CAN.

Reports don't save companies. The discipline needed to keep a clean,
accurate set of books does, and that could be done in databases,
spreadsheets or even paper & pencil (gosh, there were companies that
made money before there were computers?!). I'll bet Enron produced lots
of DBMS-generated reports, fat lot of good it did their shareholders
and employees!

 

[Harlan Grove]

Jamie Collins wrote...
....

Here's an Access/Jet stored proc to calculate as per your moving
average example:

CREATE PROCEDURE harlen arg INTEGER = 1) AS
SELECT T1.row_ID,
(SELECT AVG(T2.data_col)
FROM Test AS T2
WHERE T2.row_ID BETWEEN T1.row_ID
AND T1.row_ID - arg - 1))
AS moving_avgerage
FROM Test AS T1;

:arg replaces your value in cell C$1 i.e. a parameter used to vary the
number of points in the moving average.

Is row_ID necessary in the result table?

From the 10 minutes I spent on it I can't be not sure this is 100%, but
you can see that the solution *is* a simple (elegant?) subquery and
certainly does not require an extra join for each number of points.

Dare I suggest your 'spreadsheet mentality' prevent you from seeing
this <g>?

Possibly. Now you get to deal with the remaining abstractions that
spreadsheets can provide:

=AVERAGE(OFFSET(INDIRECT("'"&WorksheetName&"'!"&DataColumnRange),
ROW()+K,0,N,1))

That is, how would you go about making the table and field names
parameters as well?

But nice that someone rose to at least one challenge. I figured it was
beyond Aaron's grasp. So moving along to another, wanna try the one in

http://groups-beta.google.com/group/microsoft.public.excel/msg/2c1e73ffd974b4d2?dmode=source&hl=en

(or http://makeashorterlink.com/?G1082238B ).

 

[Harlan Grove]

Jamie Collins wrote...
....

The point is, SQL does data management so well that it's hard to
justify using anything else.

....

Fine. If one needs to perform data management, as distinguished from
data entry (so managing data already entered in some in-house computer
system), then I agree rdbms's are usually best.

It's the mathematical manipulation of that data that generally isn't
well suited to rdbms's.

I'm not bitter; in fact, I find it amusing. The gurus in the Excel
newsgroups prefer VBA loops because it is more palatable to the newbies
and VBA dabblers (procedural mindset, difficult to think in sets, etc).
The same gurus probably know and use SQL in their professional capacity
but they, like aaron, also know the truth: if SQL is best for data
management then Excel is not the tool for data management.

Agreed. However, management isn't the only thing one does with data.

There's also the question whether OPs have access to Access. Excel is
on lots more PCs than Access, and even if one has Access doesn't mean
one can do anything more than run SELECT queries against company
databases. So, if OPs post in Excel newsgroups, respondents are on
solid ground assuming they have Excel. It's much less safe to assume
they have Access, and giving Access-only replies is at best off-topic.

That said, I agree about the overuse of VBA and procedural code in all
the Excel newsgroups other than .programming. Myself, I try to stick to
formulas to the greatest extent possible and resort to VBA only to
extend formulas for the most part. I've made a few naive plugs for
using SQL.REQUEST instead of complex array formula, but have stopped
doing so after learning of memory leak problems with it in some
versions.

 

[Harlan Grove]

Jamie Collins wrote...
....

Here's an Access/Jet stored proc to calculate as per your moving
average example:

CREATE PROCEDURE harlen arg INTEGER = 1) AS
SELECT T1.row_ID,
(SELECT AVG(T2.data_col)
FROM Test AS T2
WHERE T2.row_ID BETWEEN T1.row_ID
AND T1.row_ID - arg - 1))
AS moving_avgerage
FROM Test AS T1;

....

Forgot to point out that this would only be useful to people who have
sufficient rights to create stored procedures in their companies'
central rdbms's. So not useful for most non-IT dept users.

 

[aaron.kempf]

sprocs and views ARE written with Access. It is called ACCESS DATA
PROJECTS. MDB is friggin dead.. SQL Server has taken over the world.

I still disagree with your understanding of the popularity of Access.
I dont think that there is a single company in the nation with more
than 5,000 employees that doesnt have Access installed on SOME of their
desktops.

Over the past 7 years; I have been at a half dozen companies with over
ONE HUNDRED access databases.

That is a lot of reports...

Access isn't aimed for IT people. Access is aimed at end users.

Having end users create views and sprocs-- that is not as bad of a deal
as it sounds. I learned to write queries in Access after an hours'
worth of training. Not that big of a deal.

I just strongly disagree with your understanding of Access on the
desktop. And even if your end users dont have Access; they can still
use the Access Runtime if ONE person at the company buys Office 2000
Developers edition.. I'm not sure of the licensing with newer versions
of office; I just dont have time to deal with companies that aren't
willing to invest in their workers.

and just for the record; cutting and pasting data between worksheets---
running macros--- that is NOT an automated manner.

basing your reports on queries that you store on the SERVER --- as is
FREE with MSDE and Access Data Projects-- this is the best way to run a
business. Since you can change a sproc in one place instead of
changing 100 MDB queries.. or instead of changing 1,000 spreadsheets.

I just dont see the logic in usgin Excel at all.

It is absolutely a disease. You guys are a disgrace to your companies;
modernize, or be kicked to the curb.