(e-mail address removed) wrote...
i could insert 3 columns into 4 columns with an append query.. it's
easy
....
I don't doubt that it's easy, but it's ill-defined without specs.
without specs, entering NULL into each field in the destination table
is every bit as meaningful as entering the concatenation of the 3
fields in the source table into each of the 4 fields in the destination
table. Only one-to-one mappings with very similar field names are
obvious.
That wouldn't take me more than a couple of minutes to write-- and that
way when people hit C it would first select Chicago.. then if they
started typing CHA it would change to chatanooga
And you'd need a link to this table in every form in which someone
would want to use it. Not a bad thing. But now a complication. What if
there were multiple processing centers. People in Denver might want the
topmost S entry to be Salt Lake City, UT, while people in Boise might
want it to be Seattle, WA. If they use keyboard mapping, they could
customize key combinations which are most useful for their own
situations. Much easier than each of them writing their own table of
personal sort orders.
and I really dont care for Excel vba -- -- for a bunch of reasons
a) it is WAYYYYYYYYYYYYYYYYYYYYYY too easy to have 100 pages of excel
vba
b) it is WAYYYYYYYYYYYYYYYYYYYYYY too complex to have 100 pages of
excel vba
More proof you don't know what you're doing. If you leave Excel's macro
recorder on during a long session, you can get VERY LONG macros. If you
change a single print setting while the macro recorder is on, it
records not only the setting that changed but all the other settings.
It's less than ideal. (Lotus Symphony's keystroke recorder was the last
minimal recorder that shipped with a spreadsheet.)
But real developers only use recorded macros as a starting point, and
they only record short bits at a time. Then they parametrize the
recorded macros and write macros that stitch together the operations
they need to perform in a logical and EFFICIENT manner. If you don't do
that, it's not Excel or VBA that's to blame.
i just want more power from excel; i just dont think that it has the
functionality that it needs for me to use it on a daily basis.
....
Because you may not need the functionality it offers.
and i mean.. people use excel for data entry all the time. that just
drives me crazy.. i mean-- you can't validate numbers, you can't DO
Anything with the numbers. Excel is just CRAP.
Batch validation after entry. Using formulas. Not difficult.
my first computer job; they sat down 30 of us kids and taught us all
Access queries in about 20 minutes.
....
Never had a 'computer job'. All the jobs I've had have involved
computers, but I've never been in MIS/DP/IT, never been exclusively a
programmer, never used only one type of computer (I've always had jobs
that have required some mainframe SAS use/programming).
Excel just FAILED to meet my needs.
And so you believe it fails to meet anyone else's needs?!
I mean-- can't they give me a way to say 'try this relative formula for
this whole column' rather than 65k rows of the exact same thing (well,
it's not the exact same thing; and that's the problem).
Multidimensional modeling software like Lotus Improv (defunct) and
Quantrix (currently available) have been available since the mid 1980s.
They never caught on. Can you figure out why not?
Spreadsheets *are* poor tools to use for canned reports unless the
reports are very simple and require very little data which comes from
outside sources.
Most large companies use some form of OLAP software, but most of those
are definitely not end user tools.
There's a need for ad hoc calculations, and spreadsheets have proven to
be the most efficient tool for them for most computer users. Trouble
comes when ad hoc models become widely and regularly used. Even then,
it's possible to design robust and efficient spreadsheet models, but
few spreadsheet users have the broader programming skills to know how
to do it. That's why there are a lot of poor quality spreadsheet models
in use out in the wide world. But spreadsheets are still very good ad
hoc calculation tools.
To repeat yet again, use the best tool for the task. That doesn't
always mean spreadsheets, but it also doesn't always mean databases.