all im saying is that it should be YOU and not HIM that is writing the
databases.
Once you know Excel, it is natural to GROW into databases.
Most of you people are too stubborn to do it.
So BASIC is unloved; except for the FACT that it is the worlds most
popular language on the worlds most popular platform.
And didn't you just illustrate how EVERYONE LOVES BASIC?
If BASIC wasn't loved outside of the Windows world; why would
mainframes have VS BASIC? Why would macs have RealBasic? Why would
Linux have XBasic
It is the world's most popular language..
You don't need to learn VB/VBA you need to learn MDX harlan or else
you're roadkill.
there is no such thing as an array.
there is only databases.
anyone tries to tell you otherwise and they're tryting to sell you
something
why would you reinvent the wheel?
i was watching some ESPN show the other day; and they were talking
about coaches being able to consume tons and tons of videos-- and i
swear to god i saw NFL coaches sitting there; wading thru hundreds of
movie clips using-- guess what-- Microsoft Access. A nice lil
application with forms and a couple of wizards.. it was obviously
written in MDB or ADP I coudnt' tell.
if it is good enough to run your company off of; and it is good enough
for the NFL coaches-- why the hell isn't it good enough to automate
your reports, loser?
....re: pdf
....For you LOSER EXCEL PEOPLE Microsoft came out with a PDF killer back
for Office 97, it is called the 'snapshot viewer'
It allows you to export a report into a small file (much smaller than
PDF) and emial it around making it portable.
....Microsoft can't compete
Access must be the answer to a bonehead's prayers.and Access fits my needs-- it has a PDF viewer included called the
'Snapshot Viewer (.SNP extension)
you guys try to use excel as a one-size fits-all solution
except excel doesn't scale to 66k rows and it sux because it is SLOW
and can't be trusted.
it isn't stable.
excel is over-used and it is a disease
hahahhaha
and electricity is so 1890s
it's like -- Databases are the best Long-term solution
If you're too lazy to use databases; keep on using Excel
I just wish that Microsoft realize that they're sending us all to
hell by mandating that people use XLS.. mainly becuase they refuse to
fix bugs in thier other programs.
If there is a bug in Excel; they'll fix it.
If there is a bug in Access-- they won't.
Not because of marketshare, not because of profitability or anything
like that.
The problem is that you damn beancounters are LAME
and you guys need to wake up and start doing thigns more efficiently.
You beancounters make the same spreadsheet month after month.
I might take twice as long to make the same report in Access (or SQL
reporting services for example)
And after 2 months; i have saved time for my company-- because it is
FREE and EASY to schedule a report that gets printed using Access.
Printing a new monthly report in Excel means that the beancounters
have to spend an hour cutting and pasting data.
It's just funny grow up guys and learn databases.
-Aaron
I know for a FACT that these 'professional applications' don't use
Excel.
I am positive that they are database driven.
GROW UP AND LEARN SQL KID
jackass
go and bark up some other tree.
VB is the most popular language in the world
The fact that Firefox and opera don't allow client-side vbScript has
nothing to do with security.. go and play with your mac in red china
you commie
just because VB is popular; and it has some vulnerabilities-- that
doesn't mean that it's a bad choice for client-side scripting.
ActiveX downloads in IE might be a bad idea.
But vbScript is innocent and very powerful
Java BS is for wimps
[email protected] said:hahahahahahahahahha
give me a break; you can't link to Excel reliably.. what if someone enters a
number in a date column LoL
I do have a blind hatred for Excel.. but I'm also pretty decent with it.
I just know that there are MILLIONS of people out there that create the same
report week in and week out.. and I am here to tell you guys to grow up and
start usign a real platform.
Excel is dead.
Excel is dead.
Excel is dead.
Excel is dead.
Excel is dead.
Excel is dead.
Excel is dead.
Nick Hodge said:Aaron
Importing data out of a spreadsheet is BROKEN, DOESN'T WORK AND IT NEVER
HAS.
Surely you import in and export out?
Anyhow, how is it broken. The number of times I link Excel tables into
Access each week and run append, select, delete queries is immeasurable.
After that I run the data into Excel using ODBC to form an intuitive pivot
table, chart, etc.
When will you realise that interoperability and 'right tool for the job' is
key, not a blind hatred for one or the other?
--
HTH
Nick Hodge
Microsoft MVP - Excel
Southampton, England
(e-mail address removed)
the only thing that is 'built into a spreadsheet' is the ability to flush
hours down the toilet.
If you're too narrow-minded to consider that doign _SOME_ of the work on
the
database side makes sense.. then uh.. go ahead and write spreadsheets for
the rest of your life.
The thing that will please you nasty beancounters the most-- if you want
to
push dfata into a spreadsheet; access supports this functionality. Once
you get data into a database, it is EASY to pull it into Excel.
Access is a 2 way street; SQL is a 2 way street.
Importing data out of a spreadsheet is BROKEN, DOESN'T WORK AND IT NEVER
HAS. It is impossibly to have adequate field validation in Excel... by
definition; it is impossible. In Access, there are input masks and all
sorts of tools that make it easy for a 3rd grader to have accurate,
consistent data.
You spend all of your time typign numbers from Excel; and you have this
house of cards-- formulas on top of formulas.. there ISN"T a decent way to
check for broken formulas.. (unless you like priting out the formulas and
LOOKING for them GAG)
Microsoft just doesn't test it or something.
And about perl, shove it up your a$$; VBA is the _ONLY_ language in the
world. If you want to index data; store it in SQL-- if it is too slow;
then
give it an OLAP interface. It is simple simple simple stuff if you knew
anything about databases.
Do you really think that this:
"=AND(ABS(TRANSPOSE(ConvRates)-1/ConvRates)<1E-12)" is intuitive?
I think that the SQL Statement is perfectly intuitive.. but after all of
your bitching you guys still dont understand that I could duplicate the
storage of your matrix in a db and it would be this:
select USD from currencyconvertor where source 'GBP'
I can use the exact same format you use; and it is twice as easy to get to
this data.
get out of your cubicle and get into the real world kid
All I know is that companies-- AS A WHOLE-- need to hire about 2x as many
database people as they currently do.. and then need to fire about half of
their beancounters.
Being able to automate beancounters is what the 'pc revolution' is all
about.
You guys are targets; in an ideal world-- we would have automated your job
already.. but the sad thing is that there is this DISEASE called EXCEL and
people think that it is ACCEPTABLE to print the same report by hand every
month.
Grow up and welcome to the future
RE:
If you mean reports, then I don't disagree that databases could be more
efficient in some instances. However, there's a question of how many
calculations (not the simple database sort of accumulations - SUM,
COUNT, AVERAGE, etc. - but rather more complex ones like the a_th
percentile of a statistical distribution with parameters based on
sample data) are needed to produce the results of interest.
This type of person should be locked up in jail for being egocentric.
SQL Server has the ability to make user defined functions.
No, really?!
Most useful software possesses the attributes of modularization,
programmable extension and the ad hoc ability to run other software.
That said, while one could write a udf for SQL RDBMSs to calculate, say,
estimators and standard errors for linear models, it'd unpleasant to do
so.
That sort of thing is built into modern spreadsheets but not databases.
Now one could use a database as the storage backend for a stats package,
but
it'd be the stats package that does the real work, and only after it
loads
the data into its own data structures. I agree that databases are very
good
storage and retrieval subsystems, but I remain unconvinced that the forms
and reporting tools provided by most databases are vastly and uniformly
superior to the alternative provided by spreadsheets (when properly
designed). But calculations using udfs leads to UI/front-end vs
processing/back-end interface issues.
Consider something as simple as the currency conversion rate table
discussed
before. If there were no conversion fees reflected in the conversion
rates,
then one would expect, e.g., the conversion rate from US dollars to UK
pounds to be the reciprocal of UK pounds to US dollars. So if the foreigh
exchange markets were perfectly efficient, the matrix of conversion rates
should be characterized by the entries in its lower triangular matrix
being
the reciprocals of the entries in its upper triangular matrix. In Excel
terms,
=AND(ABS(TRANSPOSE(ConvRates)-1/ConvRates)<1E-12)
where ConvRates is the N-by-N matrix of conversion rates for N
currencies,
which are unity along the main diagonal.
This can be done with an inner join of the table with itself swapping the
country fields in the second reference into the table. Something like
SELECT (Count(*) > 0)
FROM (SELECT [CT1].[ConvRate] = 1/[CT2].[ConvRate]
FROM CurrTbl As CT1 INNER JOIN CurrTbl AS CT2
ON (CT1.ToCountry = CT2.FromCountry) AND (CT1.FromCountry =
CT2.ToCountry)
WHERE ((Abs([CT1].[ConvRate] - 1/[CT2].[ConvRate]) < 1E-12)));
Does the latter really look clearer to you?
Anythign that you can do in Excel; i can do in either MDX or SQL. And
I'll
do it once; and make a couple of DTS packages; and I am done-- I don't
need
to come back and type stuff into a spreadsheet in order to make a new
report..
Further to the example above, I could parametrize the table name in
Excel,
so the formula would become
=AND(ABS(TRANSPOSE(INDIRECT(CTN))-1/INDIRECT(CTN))<1E-12)
How do you do that in SQL without resorting to some metalanguage or
creating
temporary tables using common, reserved names?
I tell you this-- if spreadsheets were all-powerful. you know those
supercomputers that they have?? They would be runnnig Excel.
Who wastes money running databases on supercomputers or networked
clusters?
No one in their right mind. They run hand-crafted FORTRAN or C code if
they
want to get anywhere past single-digit gigaflops. Do you believe such
programs rely on realtime database feeds? No way. They use cached,
multiplexed data pipelines. And they don't waste runtime writing results
to
databases but to many synchronized output streams. Possibly databases
populate the inputs and store the outputs eventually, but this is just
another example of databases being the backend storage subsystem. A
useful
supporting role to be sure, but hardly center stage.
If Excel was really the best solution-- people would have Clusters of
spreadsheets. Excel 2005 Cluster Edition...
No more than they'd have clusters of DBMSs. Neither are the right tool
for
the task. And no one uses supercomputers of clusters for generating
reports.
Time for your next straw man.
explicit and reproducible.
They're much less so in other systems, including DBMSs.
They're reproducible because you CUT AND PASTE THE FORMULAS INTO 1,000
DIFFERENT CELLS.
Yup. No one said audit trails are storage efficient or free from
unintended
screw-ups. Rather, it's easier to locate such screw-ups.
I CAN DO THE SAME THING ON THE DATABASE SIDE--
No you can't. The source tables, the definitions of the views or the
queries
could be modified. If a user calls the same named stored procedure in
March
and April, that user has no guarantee other than the word of their
database
admin that nothing has changed other than the addition of data from the
month of April.
Historically this has been addressed in mainframe reporting by including
checksums, tape volume IDs, record counts and other stats derived from
inputs along with full JCL and key procedure listings in printouts. To
repeat, no one said audit trails were storage efficient.
BUT I CHOOSE TO KEEP MY BUSINESS LOGIC IN ONE PLACE-- SO THAT IF I NEED
TO
CHANGE A REPORT: I CHANGE IT IN ONE PLACE.
...
It's the need to prove there have been no changes in that business logic
between report runs that's the nasty problem. It's actually pretty easy
to
show the formulas in two different workbooks are identical or
substantially
similar. As long as printouts (which could be text files) of business
logic
are included in the master copies of reports, there's a true audit trail.
As for change in one place, that is a definite advantage of databases.
However, using standard templates as the basis for spreadsheet reports
also
provides centralized change management.
In spreadsheets the key is to separate storage of user inputs from
calculations. [IMO, this is much easier in Lotus 123 and Quattro Pro than
Excel.] Then the only thing that would need to be stored would be the
user
inputs. All the 'business logic' (dare I call it formulas and macros?)
....Sure it wasn't many posts that happened to get merged because they had the
same title?
Care to share it with us.
Sure it wasn't many posts that happened to get merged because they had the
same title?
Care to share it with us.
Bob Phillips said:Sure it wasn't many posts that happened to get merged because they had the
same title?
Real newsreaders thread by reference. said:Care to share it with us.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.