H
Harlan Grove
(e-mail address removed) wrote...
Meaning not everyone would be able to do it.
Granted, though Access macros can run malicious code.
How many organizations would give new database users the ability to
schedule *any* jobs right away?
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?
You mean because it'd be EXACTLY THE SAME for Access as for Excel you
want to downplay it?
Using VBA, so again possible in the same way in Excel, i.e., via
Automation.
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 Autpen. 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.
Wrong end.
....of course it requires permissions
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 Autpen. 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.