Re: why>?

I just know first-hand that there is a better way

i know that you kids squirrel away in Excel all day long; and i call
that a travesty.

building reports in Excel should be grounds for termination.
it isn't a real reporting tool.

it wont ever be.

do people TELL you to use excel?

Have you ever asked why?
Is excel a 'standard'??

It just breaks my heart to see you guys slaving over the same silly
spreadsheets week in and week out




Harlan Grove wrote:
aaron.kempf@xxxxxxxxx wrote...
...
MICROSOFT WILL MILK THE *** OUT OF YOU EXCEL DORKS; AND YOU STILL
WONT HAVE THE POWER AND SIMPLICITY THAT YOU NEED TO GET YOUR JOB
DONE.

We may not have the software to do YOUR job, but since you have no clue
what anyone else's job involves, you have no clue what software anyone
else should be using. That's why you're left always having to assume
everyone else does the same thing you do.

If Ms made a version of excel that LOOKED just like Excel; but it
stored everything in SQL Server-- maybe that would be something that is
worthwhile.

Store the values and the formulas in SQL Server.. so if i need to
update a whole sihtload of 10,000 functions; i can just use a simple

UPDATE XLS_FORMULAS
SET FormulaText = replace(formulatext, 'TRIM', 'LTRIM')
WHERE Worksheet = ''sheet1' and row = 'A'

Kinda missing the entire point of spreadsheets, aren't you? First,
while there's a TRIM function, there's no LTRIM function in Excel, only
in VBA. So your wonderful batch replace operation would result in a lot
of error values. And, assuming for the moment there were an LTRIM
function, what would happen if there were already a mix of TRIM and
LTRIM function calls in these formulas? You'd replace the LTRIM calls
with LLTRIM. You need finer control over text replacement when dealing
with formulas. Once again your inexperience/lack of understanding leads
to errors any moderately competent spread*** user would avoid.

Second, columns are identified with numbers, not rows.

Third, you'd need to limit this to specific workbooks wouldn't you? Or
can your wee brain only imagine that all workbooks would have the same
formulas in the same places?

I mean seriously; if Excel had more functionality-- to be able to
update this sort of crap--- without using a dangerous Excel macro--
then maybe i would be happy with excel.

The danger of data corruption is no different using Excel macros or, if
they were possible, SQL-like Update queries. As your screwed-up code
above demonstrates, SQL-like Update queries can mung formulas quickly.

Besides, in order to gain the finer-grained control over tokenized
replacements in formulas, you'd need to use VBA or some other
programming language to implement regular expression search and replace
so that it would be possible to replace TRIM but not LTRIM (or more
realistically, NPV but not XNPV) calls.

Finally, VBA is only a clear & present danger in the hands of
incompetents like you. There are ways to protect against macro viruses
ways to avoid needing to use macros in workbooks in production and used
by others while still using macros during development.

if i could source an excel workbook with data from a sproc.. and i
could take input parameters--- then maybe I would stop bitching and
moaning.
...

You can already if you knew how to use ADO, VBA and Excel's object
model. The problem is that you only know how to write SQL queries, so
for you everything must be a SQL query because that's all you know.

And Excel STILL isn't a multi-user application.

Wrong. Spreadsheets as glorified calculators are multi-user in the same
sense that multiple users can access Google web search at the same
time. That is, when users don't need to share what they're working on.
When they do need to share, there are shared workbooks. There are some
restrictions imposed in shared workbooks that don't apply to isolated
user workbooks, but they're not onerous if the spread*** is designed
to do what spreadsheets are supposed to do - lots of calculations
involving relatively little data. If you mean Excel does a poor job as
a multiple user database, granted, but that's not what Excel or any
other spread*** were designed to do well.

If we could leverage Excel reports inside of SQL Server Reporting
Services; then maybe Excel woudln't be so friggin worthless.
...

Using Excel to generate reports is problematic. It's not the ideal
tool. However, since you only seem to understand reports, you naturally
focus on this.

so instead of 'do you want to open this read-only and make YET ANOTHER
COPY OF THE SAME DAMN REPORT'
...

If some spread*** is meant to generate reports, then users presumably
aren't adding any data, just applying different filters or views (in
the Excel sense). Such changes shouldn't be saved.

So I claim that the problem is that you excel dorks are
one-trick-ponies.
...

If we all only used Excel, maybe. But many of us use Excel AND Access
AND other dbms's AND other programmable software. You're the one stuck
with a software monoculture and the easily outsourced/off-shored job
domain.

if Oracle saw value in excel they would have a competitive product.

They used to have SQL*Calc, which was pathetic as a spread***. They
figured out that it wouldn't sell any units of the RDBMS, and might
even drive some customers away. They, unlike you, figured out how to
spot their own mistakes.

that is why there is only one vendor for spreadsheets... because most
technology ocmpanies says 'who gives a *** about spreadsheets'
...

Or because there's no point competing against a network monopoly (this
is an economics term). Then again, weren't you ranting about Google
Spread*** just last week? Where's Google DBMS?

So who gives a flying *** what 80% of my posts say.

Even a ranter can state the bald truth at times. 'Course it'd be more
accurate if you bumped up that percentage.

I am here to say what needs to be said.
...

'The Excel-using aliens are coming! They'll suck out your brains with
nested IFs!'

.

Loading