anybody that ever types anything into excel is an EXCEL DEVELOPER.
And anyone who ever wrote a batch file is a system administrator?
Is everyone who uses Word an author?
Don't be scared to learn how to actually use the tool.. it's amazing what
you can do; once you drop the fear of VBA Macros. People are SCARED to be
seen as a 'developer'
And most of what *should* be done with Excel can be done without any VBA
code. VBA makes it easier to extend Excel spreadsheets, but most of the
resulting applications probably should be rewritten in other languages to
make maintenance easier in the long run.
It's not so much that most Excel users are scared to be seen as developers.
It's more accurate to say that Excel use (or any other software use) isn't
the core of their job. Software are just some of the tools they use. They
don't want to be considered developers because they don't want to find
themselves limited in what they can do to just application development.
Excel and Access have blurred the lines between developers and
beancounters-- but most of the beancounters i know need to wake up
and start learning a 21st century toolset.
If you assume such tools are exclusively developers' tools, then it's
consistent (though somewhat circular) to believe anyone who uses them would
be a developer. Me, I'd give more weight to *how* the tools were used. I use
hammers, drills, screw drivers, saws and even planes, but I guarantee you
I'm no carpenter. It's quite possible to use these tools as a developer, as
a user, or as a putz.
No developers on my side have ever been too busy. You management-type have
just been going the wrong angle-- trying to make everything web-based.
....
Like web-based spreadsheets!
It's nice you have underemployed developers with lots of time. I've never
worked for a company where developers weren't intentionally backlogged. Even
so, what may be true now has little bearing on what was true back in the
mid-1980s when spreadsheets emerged as the software development platform of
choice for anyone & everyone outside IT/MIS/DP departments. You're ignorant
of early PC history if you don't know that one of the reasons they became so
ubiquitous is so that non-IT departments could automate (in a very loose
sense) certain tasks (but *not* all tasks, and often not the more important
tasks, just the recurring mundane ones) that the developers weren't willing
to touch.
The reason few people want to be classed as developers is because in most
companies that sell non-computer/non-software goods and services, developers
had reputations as arrogant and unresponsive, and they seldom rose from
their department into senior management. Obviously you're an exception - no
arrogance or ignorance in any of your opinions so far, gosh no.
You can't query a spreadsheet. It's just a dead end street..
?
Excel is an ODBC data source, so in a picky, techincal sense you're dead
wrong.
*IF* the spreadsheet were designed with reuse in mind, key calculated values
would have descriptive defined names, and those could be dereferenced,
though not queried. This would be not much different than polling the
message stack, accessing the system date/time or dereferencing environment
variables. In all systems, there are a lot of data/information sources that
aren't queried (unless you expand the defintion of 'query' so broadly that
my objection in the previous paragraph ceases to be picky).
Mdx, by definition-- can do anything that a spreadsheet can.
Again, genius, how do you use it to create an amortization table?
There's a world of difference between 'can do' and 'can do better'.
The thing is that you dont understnad-- is that you wouldn't ever need to
display this single field-- you can join a few tables in order to get the
results that you really want.
No, really?!
You're not understanding that one of the big differences between
spreadsheets and most other application development platforms is that in
spreadsheets most of the data structures and temporary variables are
available for display. There are many time when this is desirable. When it's
not, they can be hidden (perhaps not so that determined uses could never see
them, but hidden enough for most users).
Rather than exporting your data to excel from this database; and looking up
each value for an exchange rate-- and then displaying it in a 3rd field--
you can buidl a QUERY that would translate between those 2 and then you
would be much better off tomorrow.
You'd need to create a parametrized query to make this as simple as it would
be in spreadsheets. I see you fell into a trap I laid in
HLOOKUP("USA",CurrConvTbl,MATCH("UK",INDEX(CurrConvTbl,0,1),0),0)
Make "USA" FromCountry and "UK" ToCountry, and you have parametrized
formulas. Define FromCountry and ToCountry as single cell ranges, and use
data validation lists in both so that users would only pick from countries
in the table.
For equivalent DBMS functionality you'd need to design a form (I don't know
the proper terminology for items in such forms) that included two user
entries from lists that would be initialized from one query against the
table. Then once the two entries were set, query the table to return the
conversion rate. Seems to me there'd be 3 'fields' here too - the two
entries and the result. While the table wouldn't be part of the display,
it's unlikely it'd take up too much less storage than the N-by-N grid plus
row and column headings in the spreadsheet.
