Is it moral for a company to PAY someone to speak on a free site?
Does that happen here?
I scream bloody murder-- because most of you dorks can't imagine a more
efficient word; and I see quite a few people spend quite a few hours
trying to put out my fires.
I find it laughable.
Does Microsoft really pay you idiots to argue with me??
Nobody's paying me, and I think someone's paying you to spam this newsgroup with your
website.
good stuff... lol
seriously though. Who here gets paid by Microsoft to keep me in line?
Does this really happen on usenet? Companies pay marketing firms to
combat certain ideas??
-Aaron
Yes, It's called Nerolingustics. It's using language to change someone's mind, or even
damage people. Associations are big.
Watch CNN - they are very good at being racist while not actually saying anything
racist.
It's done by association - the same way that when you hear a song that "reminds you of a
time", an unconscious association can be formed by assigning a positive emotion to what
you want them to think, and anxiety to what you do NOT want them to believe. It's used
in advertising all the time.
When you are in the business (like me), you recognize it. Best part is, since most
people only get the very basics of language in school and never get an education in
advanced lingustics, people deny that it even exists.
Read up on "thought viruses".
-Aaron
ADP Nationalist
>Does Microsoft really pay you idiots to argue with me??
No. They don't pay us even for volunteering our time to help people.
Don't let your ego get the better of you. It's not about you.
John W. Vinson[MVP]
I don't have an ego problem.
People around here have a SKILLSET problem.
and an ATTITUDE problem.
People are free to bash ADP for all you care. but when someone stands
up to clear up the MIS-INFORMATION i get hounded like I'm some asshole?
A dozen odd people; including MVPs-- have been spreading misinformation
about ADP for years and years and years.
And somehow.. I become an asshole when I stand up and say 'this
solution blows MDB out of the water'
I just think that it's funny
and I dont know why poeple are such assholes to me.
YES... if you call me an asshole I will call you an asshole back.
YES if you're an Excel dork and you try to talk shit about my Excel
skills-- of course I'm going to bite back.
I just find it humorous you kids get all bent out of shape with someone
writing in uppercase letters..
I mean-- catch a clue kids.
-Aaron
So you're just reality-challenged?
How 'bout
http://groups.google.com/group/microsoft.public.excel/msg/372976d6fd176f56
?
>YES if you're an Excel dork and you try to talk shit about my Excel
>skills-- of course I'm going to bite back.
...
What Excel skills would those be? Your ignorance of how to print
multiple worksheets at the same time,
http://groups.google.com/group/microsoft.public.excel/msg/398d198ff2507257
just for example?
If you need to open up 9 different workbooks and print 2 sheets out of
each.. how are you going to do that without programming?
In Access? Macros are all multiple-choice and shit
it's HELLA easy to
a) do this
b) do that
c) do this again
d) do that again
without writing a DROP of code.
I can survive without _ANY_ VBA.
I can automate the SHIT out of an app without writing a single line of
code.
Without MAINTAINING 300 pages of VBA.
Can Excel???
Because Excel is marketed towards FUCKING RETARDS maybe it should have
some of this low-end functionality like Access does.
Access does a MUCH better job at printing than Excel does.
Excel doesn't even support fixed-width printing..
You couldn't print checks from Excel if your life depended on it.
In Access? Fixed-width printing is OUT OF THE BOX.
-Aaron
And you were wrong.
>If you need to open up 9 different workbooks and print 2 sheets out of
>each.. how are you going to do that without programming?
Now you're changing it from workSHEETs to workBOOKs. Just a bit
different. You'd do it manually.
>In Access? Macros are all multiple-choice and shit
...
Let's make this a level comparison. Open 9 different ADPs. Print one
report from each. How do you do that with one macro?
>I can survive without _ANY_ VBA.
...
Which is a good thing since you probably know as little about it as you
do about Excel formulas.
one APPLICATION has hundreds of reports.
Excel can't even friggin print reports.. you're right.. it's a trick
question
you got me
and for the record
under MACROS
make a new macro
choose 'RunCommand'
MSACCESS.EXE "C:\MyDocument.adp" /X DestinationMacroName
try doing THAT through the command line with your piece of shit CRUTCH
or 'Shell' if you will.
Yes, but one XLS file can have hundreds of worksheets, and one XLW
workspace can include several XLS files.
I'll return to the question you're not answering: if there were
separate databases, say a financial reporting database and a payroll
database, how would you open ADPs for both at the same time and print
just one report from each using one macro?
I mean seriously.. maybe I'm just missing something obvious.
1 XLW holds multiple workBOOKS and I can use relative paths in between
them?
Inside my XLW_- think of it as a folder-- what was the name of the old
product.. BINDER??
I can have 10 workBOOKS pointing to each other with relative paths?
and I can move all 10 workBOOKS as a single component?
I'm all about hearing a way to manage this spreadsheet mess.. If I
didn't give a shit i wouldn't be here.
-Aaron
-aaron
Nope. Just tossing it out as an example.
>I mean seriously.. maybe I'm just missing something obvious.
That'd be news!
>1 XLW holds multiple workBOOKS and I can use relative paths in between
>them?
One XLW workspace holds references to multiple XLS worbbooks. Are you
confusing Excel 97 and later XLW workspaces with Excel 4 XLW workbooks?
Microsoft could have reduced potential confusion by using different
extensions.
When you open an XLW workspace, it opens all the referenced workbooks.
Since Excel has a very perverse inability to load multiple files with
the same base filename, all files open in memory may be referenced just
by their base filenames. Full or relative paths are irrelevant for
formula references between open workbooks.
>and I can move all 10 workBOOKS as a single component?
Nope. Can you move 10 different ADPs or MDBs as a single component? Are
you confusing OS operations with application functionality?
>I'm all about hearing a way to manage this spreadsheet mess.. If I
>didn't give a shit i wouldn't be here.
Your purpose in, er, participating in this newsgroup or any other that
you've, er, graced with your postings has nothing to do with learning.
no really-- I am open to learning.. I just am off by a factor of 10
when I consider manageability in Excel.
Is there somewhere I can go to take really really intense courses on
'best practices' when it comes to Excel?
you're right.. i only understand 40% of what it takes to be a
successful spreadsheet developer.
I just can't comprehend what it's like to deal with Excel and only
Excel.
I just wish that there was something equivalent to www.sqlsoft.com for
spreadsheets-- where I could take intense courses-- and other jr
spreadsheet developers could get up to speed.
-Aaron
1) out of the box the description for RunApp states "Starts another
Windows or MS-DOS application, such as Microsoft Excel or Word. The
specified application then runs in the foreground and the macro
continues to run"
Here are the details for 'RunApp'
------------------------------------------------------------------
RunApp Action
You can use the RunApp action to run a Microsoft Windows-based or
MS-DOS-based application, such as Microsoft Excel, Microsoft Word, or
Microsoft PowerPoint, from within Microsoft Access. For example, you
may want to paste Excel spreadsheet data into your Access database.
Setting
The RunApp action has the following argument.
Action argument Description
Command Line The command line used to start the application (including
the path and any other necessary parameters, such as switches that run
the application in a particular mode). Enter the command line in the
Command Line box in the Action Arguments section of the Macro window.
This is a required argument.
Remarks
The application selected with this action loads and runs in the
foreground. The macro containing this action continues to run after
starting the application.
You can transfer data between the other application and Access by using
the Microsoft Windows dynamic data exchange (DDE) facility or the
Clipboard. You can use the SendKeys action to send keystrokes to the
other application (although DDE is a more efficient method for
transferring data). You can also share data among applications by using
Automation.
MS-DOS-based applications run in an MS-DOS window within the Windows
environment.
In Windows operating systems, there are a number of ways to run an
application, including starting the program from the Windows Explorer,
using the Run command on the Start menu, and double-clicking a program
icon on the Windows Desktop.
You can't run the RunApp action in Microsoft Visual Basic. Use the
Visual Basic Shell function instead.
-----------------------------------------------------------
so I would have a macro in each destination adp.. and RunApp for the
path to these to do with out of the box without doing anything funny.
Out of the box without writing any code
If you want more options:
2) I could schedule these reports using SQL Agent-- which comes with
MSDE: and have these sent out on a scheduled basic.. right-click
SCHEDULE would be all it would take.. the SQL Job Scheduler is _QUITE_
friggin powerful.. nothign similiar to that inside of MS Excel now is
there??
3) have a DTS package that is running in the background that runs 100
processes at the same time. I use that trick for parsing text all the
time. Does Excel include a DTS tool? LoL.
4) or if worst came to worst; I could just open multiple instances of
Acces by hand; if it gives you a hard time you can put a shortcut to
MSACCESS.exe in the sendto dir and that will get through the trouble.
Do you know what I mean-- when you have one LONG-running Excel macro
and you double-click on a spreadsheet.. and it doesn't open Excel since
'Excel is busy'
well putting a shortcut to EXCEL.exe in your sendto directory would fix
that problem as well
5) there is some shellEx or some other function / API call where you
can specify whether you want to wait or not.. I can't find it right now
and I dont really need it. Anything i do through the command line; most
of it runs from the db server xp_cmdShell 'dir c:\' etc.. get the
results from a dos command and keep them in a database? xp_cmdshell
makes it super-duper easy.
-Aaron
There's MOS certification.
Viewing Excel as developer, the best practices from other development
environments also apply to Excel. You just have to add support tools
yourself.
>I just can't comprehend what it's like to deal with Excel and only
>Excel.
...
I wouldn't know either. I tend to rely more on executables and
scripting languages for most of what I develop for other people to use.
The few spreadsheets I maintain fetch data from other files and display
the results of a few somewhat complex calculations, then have an option
to save the displayed results as text files. The workbook itself isn't
meant to be saved. That is, it's meant to be a black box.
isn't that basically 'do you know how to open excel and what the
extension is'?
i've scored in the 90th percentile in access for years and years anyone
know a free online mos test for excel??
not one; but a half dozen levels of certification.. even industry
specific..
gave 4 easy ways to do it??
-Aaron
You gave 1 using RunApp. Maybe you should check.
And about that RunApp way to do it, doesn't that presume those macros
already exist? How do you print reports in multiple ADPs if there
aren't any pre-existing macros to do it?
I've had several ADP files with several hundred reports in them before.
that's part of the beauty of ADP.. you can have 100 different reports;
slicers and dicers.. in one 2mb file instead of 100 different
spreadsheets
you make a macro in the destination ADP.
1) new macro in the destination ADP
2) select 'OpenReport' as the first step
3) at the bottom choose the report name you want to open.
4) (optional) the default view is to 'print' you can also have those
preview if you would prefer
5) (optional) enter a filter condition and / or a where condition
6) rinse and repeat step 2-6 for any other reports you want to automate
7) save the macro in Access.
8) close out of the 2nd access instance
9) RunApp the name of the CommandLine Argument to print your reports;
in an exteranl adp - without ANY programming.
you can use this for your month-end batches for example.
you can use this to print to a fax server.
i've written automated fax solutions using this methodology without ANY
friggin programming.
I prefer to output reports to snapshot and then have an async program
run the snapshot viewer to print to the fax machine.
In order to do that in Excel; you would need to purchase Adobe Acrobat
and you would also need to program.
-Aaron
Nah. Pre-existing condition.
Not always allowed. Reread my example: one ADP for a financial
reporting database, another for a payroll database. In most companies,
aside from the DBAs, only HR people have any access to payroll
databases, and other people would have access to financial reporting
databases. But assume you're a DBA who's received a rush request from a
SVP for one report from each of these SEPARATE databases. How do you
print those reports with one command?
or you have a job send these reports out.
or you have a sproc that fires other sprocs.
having SQL Server send an email with a report?
that is a single line of TSQL.
xp_sendMail has an argument where you can email the results of a
sproc.. i mean-- most reports are a single sproc anyways; so this comes
in pretty convienent
But from the VBA Side-- how would I do this??
Dim Acc as new Access.Application
Dim AdpDest
Set AdpDest = Acc.OpenAccessProject
AdpDest.Docmd.OpenReport
that would just take me a couple of seconds to bust out.
i'm late for a lunch date; i swear that there is a completely one macro
way to do it..
I mean shit you can do ANYTHING with runCommand.. i mean shit.. i'll do
it with SENDKEYS lol
-Aaron
As long as the macros exist, fine. It can be done by running another
instance of Access which runs the report in the other database.
Note that RunApp is a security hole. If it can run any outside
executable, it can also run malicious or destructive programs.
Your other approaches aren't applicable to ad hoc report production.
there's only one flavor of adhoc reports that matter.. it is called
Olap and Office Web Components.
Sub-Second; it's response time is FABULOUS.
and it allows for custom functions; etc.. and the functions aren't VBA;
they're MDX functions / expressions
-Aaron
'Ad hoc' meaning for a limited, specific, implicitly not intended to be
repeating need.
>there's only one flavor of adhoc reports that matter.. it is called
>Olap and Office Web Components.
...
Perhaps for you.
So you can't answer the question how to generate one report in each of
two separate ADPs when there are no pre-existing macros in them to
produce the reports. Guess that means it'd be the same manual process
as is needed in Excel printing worksheets in separate workbooks when
there are no macros to do it.
I just described FOUR WAYS TO DO IT
and my 'ad-hoc' in Olap is about 10 times better, faster, more powerful
and more dynamic than anything you're ever seen
now you're saying 'generate' reports
earlier we were talking about reporting on it.
for starters.. if they were 2 databases on the same server?
Select Orders.OrderDate, OrderDetails.*
from northwind.dbo.Orders INNER JOIN Northwind.dbo.OrderDetails ON
Orders.OrderID = OrderDetails.OrderID
If I wanted to refer to information from 2 databases on the same
server????
I mean seriously here
Select Employees.EmployeeID, Employees.EmailAddress, Salary.Rate
from payroll.dbo.Salary INNER JOIN Employees.dbo.Employees ON
Salary.EmployeeID = Employees.EmployeeID
If I wanted to refer to information from 2 databases on the different
servers????
I mean seriously here. I'd ave linked servers set up previouly.
sp_addLinkedServer 'SERVER2'
Select Employees.EmployeeID, Employees.EmailAddress, Salary.Rate
from Server1.payroll.dbo.Salary INNER JOIN
Server2.Employees.dbo.Employees ON Salary.EmployeeID =
Employees.EmployeeID
that's from the DATA SIDE.
>From the application side?
I've already listed 4 different ways to do that
hit the button on your keyboard labelled 'Page Up' ok??
Automation.
'Excel is busy'
that problem as well
-Aaron
yeah its' simple automation
Dim rpt as new Report
rpt.recordSource = "select * from vwMyOrders"
yadda.. yadda..yadda
and again
my VBA isn't DANGEROUS like your VBA
your VBA is ridiculous; i mean..
emailing documents around???? with DATA in them??
it's ridiclous.
having 10 different copies of the same spreadsheet?
the most ridiclous thing i've ever heard
Let's see. In
http://groups.google.com/group/microsoft.public.access/msg/f052a40437afcd8e
you mentioned running a separate instance of Access using a RunApp
macro. That's one, but that's all you mentioned in that response. Then
in
http://groups.google.com/group/microsoft.public.access/msg/a041ee2fa4522719
your #2 would be another way. Would any user be able to schedule such
tasks? If not, not general and not too useful for anyone not a DBA. If
so, unwise if any user could add arbitrary tasks to the scheduler. #3
using DTS (meaning Data Transformation Services?) seems to be a method
for running multiple processes. Maybe it is, but Windows itself is
multitasking, so it's likely launching multiple Access sessions
directly from Windows would be more efficient. Even so, unless there
were macros in place to produce the reports, this would just be a
manual process in separate instances of Access. You can do the exact
same thing with Excel. Your #4 is yet another manual approach involvong
mutliple Access instances, so no different than in Excel. Finally, your
#5 is using scripting - maybe not VBA per se, but no different than
using VBA in effect, and just like using VBA or scripting to handle the
comparable task in Excel.
So you've provided maybe two ways to do this in Access or SQL Server
that have no Excel equivalents. The first requires pre-existing macros,
and the second requires permission to schedule server tasks. All the
other ways are variations on manual processing with multiple processes
or scripting.
Really? Why?
Also note that with Hotmail at least the warning provided when
attaching MDB or ADP files to e-mails is, "The file xyz.mdb(# MB) may
be unsafe. [...]" Unsafe! An MDB file? Why would Microsoft say an MDB
file might be unsafe? Gee, I wonder. It continues, "Many recipients
would not be able to open these attachments. [...]" Really? Many?! As
in MANY people don't have Access? Imagine that! The message is the same
for ADP files. Note that it's still possible to send them, there's only
a warning.
Attaching XLS files doesn't trigger the same warning. There could be
different reasons for this. Least likely is that Microsoft itself
considers XLS files less of a threat than MDB or ADP files. More likely
is that it's just boilerplate accompanying the fact that Hotmail
doesn't support MIME types for MDB or ADP files. That is, XLS files can
be opened directly from e-mail, but neither MDB nor ADP files can.
However, Hotmail DOES allow sending them and downloading them (just
tested and confirmed).
Back to security, Access VBA is just as dangerous as Excel VBA. The
only difference is that there may be fewer ways to trigger automatic
VBA code execution in Access. On the other hand, Access macros are NO
GUARANTEE of security. If Access macros can run arbitrary outside
applications using RunApp, that'd mean RunApp could be used to run
destructive programs such as
RunApp "C:\WINNT\System32\CMD.EXE /c rd C:\DOCUME~1 /s/q"
wouldn't it? It does, in fact. I just tested it (though not on
C:\DOCUME~1).
of course it requires permissions
I described 5 ways to do it Harlan.
1) RunApp - yeah macros - simple single line, multiple choice macros--
big friggin deal
2) scheduled jobs - some users can do this; it's easy to keep secure.
it's easy to give permissions to certain functionality. Can Excel give
different permissions to different users? NOT REALLY LOL
3) 'but windows iteself is multitasking' gag me with a spoon. It's
easy to configure how many threads are running at the same time; etc.
I just think that it's funny -- you're saying 'it's not a feature just
because windows does the hard work'? That's the stupidest thing i've
ever heard of. Can Excel do multi-threading apps AT ALL? I can parse
10 or 100 instances at the same time.
4) Launching multiple instances of Access or Excel? I thnk that is too
technical for you lol
5) 4 part server.database.owner (aka schema in 2005).object
you forget -- the bottom line-- is that Excel VBA is inherently
insecure... and Access is inherently secure.
I'll find that posting i gave you
from the horses mouth
but the sheer count of threats? Excel VBA vs Access VBA?
there are 1,000 Excel VBA VIruse for every Access VBA Virus out there.
Don't bother to argue with the authority on the subject.
Access VBA _ISNT_ as dangerous as Excel VBA from an architecture
standpoint; and also from the standpoint that there are 20 Macro Virus
for Access and 20,000 for Excel.
and im not sure I agree with your findings on MDB and ADP; and whether
you can email them.
Did you email FROM HOTMAIL TO HOTMAIL?
Did you use the Outlook Connector for sending hotmail through outlook??
Did your files have VBA in them?
Did they have macros?
Meaning not everyone would be able to do it.
>1) RunApp - yeah macros - simple single line, multiple choice macros--
>big friggin deal
Granted, though Access macros can run malicious code.
>2) scheduled jobs - some users can do this; it's easy to keep secure.
>it's easy to give permissions to certain functionality. Can Excel give
>different permissions to different users? NOT REALLY LOL
How many organizations would give new database users the ability to
schedule *any* jobs right away?
>3) 'but windows iteself is multitasking' gag me with a spoon. It's
>easy to configure how many threads are running at the same time; etc.
Access is multithreading? Since when? If you mean SQL Server is
multithreading, fine, say so. And multithreading doesn't mean the
ability to run multiple processes. You had used the term 'processes'
before. Processes aren't threads. Which do you really mean?
>4) Launching multiple instances of Access or Excel? I thnk that is too
>technical for you lol
You mean because it'd be EXACTLY THE SAME for Access as for Excel you
want to downplay it?
>5) 4 part server.database.owner (aka schema in 2005).object
...
Using VBA, so again possible in the same way in Excel, i.e., via
Automation.
>you forget -- the bottom line-- is that Excel VBA is inherently
>insecure... and Access is inherently secure.
...
You've failed to prove that. VBA is VBA. There's nothing in the Excel
object model itself that's dangerous. It's the other stuff that could
be run from VBA that's dangerous. With regard to spreading viruses, it
requires automating the Visual Basic Project for each file. Guess what?
Access can do that just like Excel.
Access lacks the automatically executing macros that Excel has, e.g.,
Workbook_Open and Auto_Open. However, all it takes is one udf called
from every form, report and query to run malicious VBA code. Meaning
it's only really safe to run Access databases that contain only tables.
>from the horses mouth
Wrong end.
Just like Excel! Imagine that!
Macro security settings are common to all Office applications.
>but the sheer count of threats? Excel VBA vs Access VBA?
...
Is related to the sheer numbers of Excel vs Access users. Excel
presents a much bigger targer because so many more people use it. If
you actually convince many Excel users to switch to Access, you'll make
Access a bigger target.
>Don't bother to argue with the authority on the subject.
Who'd that be?
>and im not sure I agree with your findings on MDB and ADP; and whether
>you can email them.
Test it yourself.
>Did you email FROM HOTMAIL TO HOTMAIL?
Nope. From Hotmail to my Lotus Notes account at work, to my AOL
account, to my ISP e-mail account and to another free e-mail account.
All worked. Hotmail only grumbled, but it sent the files.
>Did you use the Outlook Connector for sending hotmail through outlook??
Nope. Straight from the browser.
>Did your files have VBA in them?
>Did they have macros?
Yes to both. The VBA code was
Sub foo()
MsgBox "So Aaron's wrong again . . . big surprise!"
End Sub
"unknown" wrote:
>
It's funny.. I've accomplished more on this newsgroups than I could
have possibly imagined-- so yes; it has been quite effective for me.
but you kids sit around and throw around words and it's like.. you kids
just can't build a coherent argument.
your logic, your architecture is flawed.
MDB is for BABIES.
XLS is for BABIES.
neener-neener, neener
you kids have no weiner
Access without SQL is just plain stupid.
not as stupid as having 300 different copies of the same spreadsheet
-Aaron
it might be related to the count of Excel DOCUMENTS vs Access
APPLICATIONS.
but I know of hundreds of people that sit around and type shit into
Access. it's only a handlful of apps.
on the other hand; you got 2 people writing in a spreadsheet and then
you need to merge them by hand/?
hahahahahahaha
rofl spreadsheet dorks are silly