Re: why>?



look buddy i have been in the 'excel replacement' industry for years


i haven't used excel for anything ever since early '99.

i dont agree with any use of excel anywhere.

excel wasn't stable enough back then-- and it's lost it's chance in my
opinion.





Harlan Grove wrote:
dbahooker@xxxxxxxxxxx wrote...
IT isn't the solution to anything

Possibly, but it's always there, and for most business users there's no
way to avoid it.

the solution is to start taking Excel development seriously.
the solution is to apply SDLC into the 'excel development process'.
...

For multiple user systems, sure. For ad hoc, single user workbooks,
won't fly.

there is no version control; there is no project management.

None built in, but there's none built into most C compiler systems
either. These are add-ons, and it's not all that different adding the
functionality to Excel. It DOES require using VBA macros to write XLS
file content as plain text to text files which serve as proxy source
files.

And I think that Excel developers should be held to the same standards
as 'real developers'.

If they write multiple user systems, sure. If they write their own
systems for repeated use, maybe in theory, but if the PERCEIVED
additional time required to follow standard development procedures
exceeds the time needed just to perform the task manually, then most
users will revert to performing such tasks manually rather than use
Excel. That's probably not in most users' or most companies' best
interests - undocumented, uncontrolled *quick* Excel use is better than
undocumented, uncontrolled slow manual processing. As for ad hoc
calculations, procedures are unnecessary and wouldn't be followed since
the alternative is pencil, paper and calculator.

Delivering a solution where you email 20mb spreadsheets around?
that gets a big fat resounding F in my book.
...

You must work with people who do that a lot. Where I work, customers
may e-mail me large XLS files (and large MDB files), but internally
we've all figured out how to share large files using file servers. Do
you need a url for an explanation of what file servers are and how to
use them?

I don't agree that it is the users screwing up data.
it is the program. Excel is incapable of true validation.

I see. People don't kill people, guns, knives, poisons, cars, etc. kill
people. Humans aren't responsible for what they enter into computers.
The software should be able to figure out when entries are wrong. Well,
actually, Excel *CAN* figure out when entries are wrong, but the
mechanism the Excel developer needs to follow to tell Excel how to
distinguish right and wrong entries differs from the mechanism database
developers would use. There is NO avoiding the fact that all Excel
work*** cells by default accept ANYTHING Excel can accept, numbers,
text or error values. Just like a Perl or VBScript variable will accept
any data type the language supports.

Programming languages (and I'm considering Excel formulas to be a
functional programming language) that don't provide strong type
checking require developers to check data types. Sad but true, so quit
whining about it. Add the necessary user entry validation procedures
such languages require, or switch to a language that provides strong
type checking.

If you want to display the data with 2 different levels of precision;
then you're storing 97 million copies of similiar formulas; and it is
impossible to validate.

?

First off, why would anyone want to view data at different levels of
precision? And if there were some reason to view the value in cell X99
using a different number format, why not use the formula =X99 in some
other cell and give that other cell the alternative number format? If
you mean that there could be many instances of simple cell reference
formulas like =X99, Oh, the horrors! How terrible! So difficult to
validate!

Do you believe anyone else still reading this believes you know
anything about how to use spreadsheets?

It is impossible to accurately force users to enter data into the right
cells; and ensure that it is the correct datatypes.
...

It's impossible to force users to do anything. It's not all that
difficult to give them NOTHING USEFUL if they don't, and it's only
moderately difficult to send their managers e-mails stating that
they're misusing systems and wasting work time when they don't. For
some users, even the threat of being fired won't be sufficient to make
them more careful in their data entry, but it does work for most users.

It's easy to check consistency of data types. If all cells in the
single column range named Rng should contain numeric values, the
expression

COUNT(Rng)=ROWS(Rng)

is all that's needed to check that. If these entries should be
nonnegative, it's only slightly more complicated to use

COUNTIF(Rng,">0")=ROWS(Rng)

How a sensible Excel developer would use such expressions appears to be
a mystery which your wee, tiny brain can't handle or you might have
figured out how to apply this technique by now given your CLAIMED
wealth of experience.

Excel vba is a disease. It is not possibly--- in any way--- to protect
against Excel viruses.

Viruses can only run when macros can run. It's possible to prevent ANY
macros from running, ergo it's possible to prevent viruses from
running. Not running them isn't the same as removing them, and I grant
that's not automatic.

the root of the problem is that emailing 20mb spreadsheets around is
not an efficient way to work. it is a security risk; it is a
performance risk.
...

Which is why sensible people wouldn't do it. You must work with a lot
of stupid people, but they did hire you, so that establishes the point.

If Excel had real reporting capabilities-- like if it could export to
SNP format (Microsoft Snapshot; currently available inside C++ and MS
Access).. then excel might be taken seriously.
...

SNP is a nonstarter. Whether or not it's better than PDF (*NOT*
Acrobat, there are alternatives to Adobe products for reading and
writing PDF files, so spare us another anti-Acrobat tirade) or not, PDF
has already won. No one outside of the people who'd hire you uses SNP.
Since Microsoft itself is pushing XPS as another alternative, looks to
me like Microsoft knows SNP is at best undead. That you can't figure
that out is expected.

I disagree that it is as simple as 'disabling macros'

first off; if i disable macros; i can enter whatever datatypes in
whichever cells i want (under your model where you have to write a
formula for each datatype).

There's a distinction here between disabling macros in inhouse XLS
models and XLS files received from outsiders. Macros in the former
shouldn't be disabled, but only a fool would run macros in the latter
without checking them first. As for inhouse models, udfs are covered
under macro security. It's easy to write do-nothing udfs that would be
called from EVERY formula. Some storage and processing overhead doing
that. If macros were disabled, then EVERY formula would return errors,
mostly #NAME? errors. The only way to get rid of the errors would be to
enable macros.

As for validation formulas, it appears the concept of batch processing
is also unknown to you. Multiple cell single area ranges require just
one validation formula. Multiple area ranges could be validated in
single formulas, but that's more trouble than it's worth, and it makes
generating useful error messages more difficult.

If I want to allow just numbers in a range Rng, I check COUNT(Rng)
against the number of cells in the range. If I want to allow just text
with at least one character, I use COUNTIF(Rng,"?*"). If I want to
allow both, I use COUNT(Rng)+COUNTIF(Rng,"?*"). If I wanted to prevent
entering just spaces as text, I'd replace the COUNTIF call with the
cumbersome COUNT(1/ISTEXT(Rng)/LEN(TRIM(Rng))).

the practical solution to this is to use MS access.

I see. Access macros can't be used to delete or alter records? Neither
can they be used to overwrite files on disk under the guise of
extracting tables to separate files?

it has real validation; access files aren't emailed around.
and even if you shut off macros; validation still works.

Access does have advantages over Excel when it comes to data entry.
When have I denied that? What I dispute is your claims that validation
is impossible in Excel. It may be impossible for you, but that doesn't
make it impossible for people who DO know how to use Excel.

there are table level and field level validations.

there are TRIGGERS where you can enforce VERY VERY complex logic.

This can be done using formulas. It may be more difficult to do so in
Excel, but it's not impossible.

excel just doesn't have a single feature of value.

More accurate would be for you to admit you don't know how to use
Excel's more valuable features. You've thoroughly demonstrated you
don't, so you might as well admit it, first & foremost to yourself.

.