Re: why>?

aaron.kempf@xxxxxxxxx wrote...
internally; sql server can support huge numbers; so i dont accept your
claim.

much larger numbers than Excel can hold lol

As usual, you're wrong because you're ignorant. In this case, you're
ignorant of the specifications of the data types SQL Server provides.
Let me hlep you.

http://msdn2.microsoft.com/en-US/library/ms187752.aspx

Follow the links for all the numeric data types. SQL Server's Real
corresponds to VBA's Single, and SQL Server's Float corresponds to
VBA's Double and Excel's *only* numeric data type. The latter group are
all IEEE double precision floating point reals.

So, what are you talking about?

And of course you don't accept my claim because it'd undercut your
arguments as well as provide yet more proof you're clueless when it
comes to calculations more complicated than checkbook register math.

it's not possible to verify spreadsheets. it is impossible to apply
software-development tools to excel-- and since 90% of the developers
at your company are 'spread*** developers' it is not practical to
double-check each and every formula, value and formatting.

You know how many developers there are at my company? Name it. Name
some of them. Or are these more empty claims and/or blather?

i have worked on countless spread*** aggregation projects-- etl
technically-- and im sick and tired of working with a tool that doesn't
have

a) accurate, provable functions and formulas

No function is 'provable' without source code *and* empirical testing.
Since Microsoft provides no publicly available source code for the
functions in any of its produces, Excel's functions are as unprovable
as SQL Server's.

As for formulas, it takes work, but it involves writing cell formulas
to text files in R1C1 addressing syntax, grouping cells that should
contain the same formulas, and verifying that the formulas are in fact
identical. That just proves consistency. The next and final step is
checking that each distinct formula does what it should. That can be
tedious for very long formulas, but not impossible.

b) accurate and strict data entry controls

You mean valid/reasonable entry. Inaccurate but technically valid
and/or reasonable entry is possible with any software, even databases.

It takes VBA, specifically, [***]Change event handlers and validation
formulas. Neither prevent invalid entries up front, only catch them and
reverse them once made. Note that spreadsheets aren't unique in lacking
transaction capabilities that databases provide. That is a strength of
databases relative to spreadsheets. However, transactions don't prevent
all errors.

c) portable method for transferring large amounts of data
....

Portable? Like ODBC? Every .XLS file may be an ODBC data source. As
such, any application capable of querying ODBC data sources could
consolidate data in .XLS files.

i find it laughable that you talk to a database person like a junior--
WE MOVE MORE NUMBERS IN AN HOUR THAN YOU DO IN A WEEK
....

Movers carry more PCs around than I do, but that doesn't make them
programmers. You move more numbers. You just don't understand what
those numers mean.

People who move stuff will always be able to find jobs working for the
people who know why that stuff needs to be moved.

.