Re: why>?

its' called

uh.. owc9.dll owc10.dll owc11.dll

it's a component in the standard office installation; if you can save a
XLS as a HTM page and 'add interactivity' and it works??

then you have it

now all you got to do it put a single button on the form in order to do
something constructive with the Spreadsheet1.XmlData property.

it's all pure XML driven.. you store those defs in a database and it's
a lot lot lot easier to search through than if you had 10,000
spreadsheets.

I literally work on a repository where we have 14,000 of these
definitions. there isn't a 65535 row limit; you can do basic
calculations; and it's a lot easier to share reports than emailing
around a 20 mb spread***.

it has relational reporting capabilities that are just blatantly more
powerful than normal XLS files.

it has pivotTables with drilldown.

its' just a magical beautiful land.

I use all 4 components from this one DLL
DataSource Control
PivotTable Control
ChartSpace Control
Spread*** Control.

it comes free with office.

you can see these things easily with a standard html editor; it takes a
little bit of toying around with the XmlData defintion in order to do
anything fun with it.

but you can loop through columns and rows; i've got a bunch of
additional buttons for standardizing cells; formatting; etc


Harlan Grove wrote:
aaron.kempf@xxxxxxxxx wrote...
dude you conceited ***

Possibly, but irrelevant.

i dont want excel functions

Do tell! Who wouldn't have been able to figure this out by now?

Access functions aren't 'just a wrapper around excel functions' you
concieted ***

You're right. They provide a subset of what's available in Excel.

and MDX isn't an add-in-- PivotTableService comes with a standard
office install.

Where? You claim this is so, so what's the name of the .EXE or the .DLL
that provides this 'standard' service? I just searched my Office 11
directory and its subdirectories for any files (*.*) that contain the
text 'MDX' or 'PivotTableService'. The only file that contains 'MDX' is
VB_XLTOC.XML, and the 'MDX' instances appear to be crossreferences into
help files or the like. There were no files that contain
'PivotTableService'. FTHOI, I also checked C:\Program Files\Microsoft
Shared and all its subdirectories, and there were no files found
containing either 'MDX' or 'PivotTableService' strings. Kinda difficult
to use a 'standard office install' feature if there's not even any
mention of it in the standard Office help files.

So, great self-proclaimed expert, where would one find this? Or is this
just more BS?

I don't agree that 'using RegExp on the desktop is the same as using it
on the server'

That's nice when running things on the server. Presumably when running
Access against local MDB files, nothing would be running on the server.
So let's assume you mean any old business PC user would be updating a
table update on a database server. Does SQL Server have built-in
regular expression support, or would it need to be added after install?
If the latter, any user given any arbitrarily restrictive permissions
could do so? Or would it require the DBA to provide such functions to
users?

for starters; you don't need to install it in a hundred different machines.

You don't need to install anything on any PC shipped in the last 5
years. WSH comes standard on any PC running IE5 or later and/or any PC
running Windows 98 SE or Windows 2000 or later. Maybe there are small
businesses still running older versions of Windows and/or IE, but it
they're still running IE4, security is clearly not a big concern.
That's off on a tangent, but my point is that any Windows user/admin
who's kept their software up to date with free service packs has WSH.

secondly; you don't need to rely on a semi-compiled languge with
inherent security problems.

Excel VBA is a disease and a threat to national security.

As would be Access VBA as well? At the very least it could be used to
launch Excel, so Access is therefore about as unsafe, no?

For the record; no you CANT create functions and share them with the rest of your
company.

OK, so you have no clue how add-ins, either XLA, XLL or COM, work.
Since you have no clue in general, not surprising you have no clue
about the particulars.

Out of the box; a function created in SQL Sever; if it is assigned permissions to the
public role-- less than 2 words-- then anyone can use it.

So there are out-of-the-box regular expression functions in SQL
Serrver? What are their names?

what do you have to do; keep a centralized XLS for company-wide macros on a UNC?

Not an XLS file, either an XLA, XLL or COM DLL file. And while it could
be accessed from a single, common UNC path, most sensible companies
with WANs would put a copy into each regional office's file server.
And, yes, there are network management tools that do handle replication
of files between HO and regional servers that would ensure that the
files on the regional servers are the same as the files on the HO
servers.

and then you go and email yourself the XLS at home and you can't use it; so your
code gets ALL SCREWED UP since you dont have the reference.

Reference in the VBA sense?

As long as there are no namespace collisions, e.g., loading different
add-ins that both contain a function named foo, file pathnames and
module names aren't used for add-in functions. This is different from
functions stored in modules in XLS files, but this is perhaps the key
difference between XLS and XLA files. I can have FOO.XLA loaded in
\\mycompanyserver\shared\whatever, and call it's bar() udf in formulas
in myfile.XLS, then save and close myfile.xls, COPY FOO.XLA onto a
local drive, disconnect from the network, open Excel, open FOO.XLA as
an add-in from the local drive, then open myfile.XLS. Guess what? The
formulas in myfile.XLS will automatically call the bar() udf in the
local copy of FOO.XLA.

How little clue do you have about using Excel?! Do you know anything
other than the arithmetic arguments and the functions it has in common
with SQL? You done a fine job showing you're completely ignorant about
damn near all Excel's intermediate to advanced features.

seriously-- how do you share functions; ***??

By putting read-only XLA, XLL or COM add-in files into shared
directories on file servers OR by making them part of the standard
software image so the next time users log in while connected to the
network the add-in files are automatically distributed to their PCs. As
for having them load automatically whenever Excel starts, all it takes
is adding one value for each to the Registry. And before you rant on
about the insecurity of Registry changes, IT departments in medium to
large companies make not infrequent changes. It's part of current,
broadly accepted IT practice.

But don't let that stop you from ranting on (& on & on).

I don't believe in using Excel VBA for anything.

Any 'function' that you need in Excel-- is also present in Analysis
Services.. which means I can create *** that is just as powerful as
ANYTHING that is possible for you.

Nope. Two examples: MDX's LinReg* functions just handle single variable
least squares regressions. Kiddy stuff. They may not be able to handle
multiple variable regression modeling because MDX also lacks any matrix
arithmetic functions.

Like I said, it can do the simple numeric stuff which, to be
charitable, is all you know how to do. So it may be adequate for your
needs, but not mine.

but I can do it with sub-second response times against billions of
records.

Only the simple stuff that's already cached. Not a chance you'd get
subsecond response time performing any operation on thousands of
records if none of the calculations were cached. And it's unlikely that
any calculations involving MDX's LinReg* functions would have been
cached unless someone had set them up to be cached.

you can't even scale 66,000 records.

Don't need to. Very little statistical data requires more than a few
hundred observations per variable. On the other hand, more than one
independent variable is usually needed, and it seems MDX can't handle
that at all.

oh yeah; i forgot 'you dont create reports'
...
So how does that not involve 'making reports'
...

Calculations aren't the same thing as reports unless you (and I'll
stress *YOU*) adopt the incoherent definition that any human-readable
output generated by computers is a report.

But how is 'report' defined in dictionaries? FTHOI,

http://dictionary.reference.com/search?q=report

gives the following definition for report as a noun,

'An account presented usually in detail.'

OK, details are optional, so reports don't have to include details. But
now need to define 'account'.
http://dictionary.reference.com/search?q=account gives the most likely
definitions as

A narrative or record of events.

or

A precise list or enumeration of financial transactions.

Most of the calculations I perform are neither related to actual events
nor are they based directly on enumerated financial transactions. I use
derivative information. Anyway, a report is a snapshot summary of past
transactions or other quantifiable events. Pro forma reports would be
analagous summaries of forecasted future transactions/events treated as
if they had already happened. I don't produce retrospective (typical)
reports or pro formas. I provide a handful of figures, which, along
with a few other handfuls of figures from other people, determine
target pricing for contracts. Supplemental to that, I also estimate
decreased profitability if we'd need to charge less than target
pricing. Maybe estimates can be presented as reports, but it's not
necessary to do so, and I don't.

Excel doesn't CRUNCH numbers.

Not as well as other types of software, but it does a much better job
of it than Access or any other database.

btw, you've never found a use for pivotTables?
...

Nope. For forecasting or exploratory data analysis they're either
irrelevant or inadequate. For some kinds of interactive retrospective
summaries of accounting data, they may be useful, but that's not what I
do. Also, pivot tables aren't automatically recalculated, so I prefer
to use formula equivalents, which are automatically recalculated.

It's the 256 column limit that's more of an unnecessary constraint.
FWIW, Excel 12 (aka 2007) will blast that away, providing more than 16K
columns. When (if ever) will Access and/or SQL Server provide more than
255 fields per table?

I have used SQL Server EXCLUSIVELY for 6 years because of the wimpy 255
column limit in MDB format.

Fair point. Excel 2007 will have 16K columns. That'll be what, 16 times
more than SQL Server?

not everything can be centralized?? why not?
...

Because it'd prevent offline computer usage. You are aware that people
use computers occasionally when not connected to networks?

.