I have two Access databases that I'm opening on the same computer. In one, running this in the immediate window works as expected (opens Notepad):
Shell "notepad.exe"
In the other, I get this error instead:
Run-time error '5': Invalid procedure call or argument
I have not been able to come up with any shell command that will run successfully in that second database. No matter what, I get that error.
What is going on here? Could there be a security setting coming into play? Or perhaps one is an older version?
Edit - More Info
When I go to the definition of Shell in the malfunctioning database, it goes to VBA.Interaction.Shell.
I get the correct IntelliSense tooltip for Shell.
I tried VBA.Shell "notepad.exe" and VBA.Interaction.Shell "notepad.exe" without success (same error).
Here are the references that are checked in both databases:
Decompiling did not help.
The culprit was our anti-virus software! UGH!
Why did it work in one database and not the other then? I'm told that years ago, anti-virus exceptions were made for my computer for the one database but not the other.
I recommend that any others who encounter this problem check their anti-virus logs/policies. Also, running the database from another computer with different policies in place might shed some light on the issue faster. In this case, when I used remote desktop to log into a server, I was able to call shell successfully.
Related
I have written a rather complex application in Microsoft Access. It is split into front end and back end files. To protect my code, I have compiled it and saved it as a runtime .accde file, which I then changed to an .accdr file to ensure it operated as a runtime. I have created two versions of the application: one for those with 32-bit Office installed and one for those with 64-bit office. I have used Inno Setup to package the application, the data file, and other files such as the icon file, the license file, etc., into an installable package, which works just fine.
Among my team of 27 beta testers of this application, so far 6 have downloaded it, and I have tested it on four of my own computers. On seven of these computers, the installation works perfectly and the application runs with no problems.
On the computers of three of my testers, when they try to run it, they get this error message:
The expression On Open you entered as the event property setting produced the following error: Bad file name or number.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
I'm pretty sure I know where the code is that's causing the problem, but cannot for the life of me figure out why the application crashes on those 2 computers but not on others.
The On Open event I suspect of causing the problem checks the linked tables, gets their connect string, then looks at the path for that string for the back end database. If it does not find it there, the procedure pops up a file selector dialog and instructs the user to find the data file, then it relinks all the tables.
If anyone could point me in the right direction to fixing this problem, I would be extremely grateful.
This is typically caused by a reference labelled as MISSING.
You have two (three) options:
Run the application on the offending machines with a full version of Access that lets you debug the code
Create a small test application that lists and verifies the references you use, and run this on the offending machines
Remove those two customers
Thanks to all the contributors here. Because of these folks and additional online research, the latest answer I can find is this:
This error occurs on a small percentage of computers on which the app is installed, and no one has yet figured out why, what causes it, or how to fix it. The workaround is to install the 2013 version of the Access runtime, as later versions will still cause the problem.
At least one of the offending computers is running the Click-to-Run version of Office. Still gathering information, but that's the status as of now.
I have a form with a button which opens a new form to add a new record to a table.
In Access on my PC (full version), everything works.
When I try to run it on a server with Access Runtime, I get an error saying something like:
this application has stopped working due to a runtime-error. The
application will now be closed
(I have the Dutch version, so I hope this comes close to the English dialog box message).
I debugged the VBA, but that doesn't seem to be the problem.
It has worked before:
Private Sub Knop62_Click()
DoCmd.OpenForm "Machines Toevoegen", , , , acFormAdd, _
acDialog, OpenArgs:=Me.Installaties_Id
End Sub
Well any un-handled error in the runtime will spit out the error message, and then as you experienced exit the application.
there are a good number of ways to approach this:
Improve error handling - make sure you don't encounter any un-handled error. I find this can be a LOT of work.
Another way? Compile your application down to a accDE. When you use a accDE, not only does the runtime ignore errors, not only does it NOT shut down?
It also means that all of your local and global variables are NEVER re-set. so global vars, and even global reocrdsets or anything else will retain their values, and do so even with errors. As a result:
Your application runs like a un-stoppable fright train.
Your local and even global variables retain their values. This allows use of application wide settings and variables that never re-set. And no re-sets ever occur even for un-handled errors. They remain intact for the given session (since the time the application was launched).
So, I would try running your application as a accDE on that server. It will not only become vastly more reliable, but it will also not shutdown on un-expected errors and even better it will retain the value of variables even when having encountered errors.
So it looks like you have some un-handed error. You can go on a treasure hunt to find this error, or just try a accDE in the meantime, and perhaps in the new years you might eventually track down the error or issue. But until then, just compile your application as a accDE.
To compile:
First, from VBA editor (just hit ctrl-g). And from the menu bar choose debug->compile. You MUST ensure that no compile errors exist before the next step.
If above compiles, then from UI (main ribbon), go file->Save and publish
From that panel, choose Make ACCDE.
Access will compile your application into a "access executable". Now try running this application with a accDE file extension on the other computer.
I have used the Shell command in MS Access for several years in multiple databases in various versions. Most recently, I have received this Run-Time error 5 - invalid procedure call or argument on a Shell command I have used for many years. Can anyone tell me if there was a recent Windows update or possibly MS Office update that has caused this error to appear? I am currently using Office 2010 and Office 2013 and receiving the same error in both version on multiple computers. I have even tried creating a simple empty database and gone straight to the vba window and in the immediate window tried a simple Shell command as such:
Shell "C:\Notepad.bat", vbNormalFocus
Notepad.bat is a simple command inside it:
cmd /C "Notepad.exe"
The code:
Shell "Notepad.exe", vbNormalFocus
does work, but:
Shell "Cmd.exe", vbNormalFocus
still gives the same Error 5 message on every machine I test it on. Running the batch files from the Windows explorer works just fine. Any help is much appreciated.
After a lot more investigation, I happened on a new software installed by our network software engineers that maintain our McAfee protection. Last week, there was a blind install of a new app called Adaptive Threat Protection and is set to check for MS office apps running shell commands, especially the CMD type. This is set to automatically block all of these such commands. I finally came to a conclusion to look in anything recently installed or updated on my computer and happen to find a few different things installed within the last week date range. Thank you for your assistance and answers so far. The answer provided by thx1138v2 were something I also tried prior to my post but I figured for my 1st question I tried to keep my post to a bit of a minimum.
For anyone stumbling upon this issue, Windows Defender can also be the cause of this behavior.
You need to check if your Security Admin configured the Attack Surface Reduction capability of Windows Defender (through Intune, MEM, GPO...).
The specific rule you need to look for here is Block all Office applications from creating child processes (d4f940ab-401b-4efc-aadc-ad5f3c50688a).
You can easily verify this in the Windows Event Viewer, in Application Logs, Microsoft, Windows, Windows Defender and then Operational and looking for warning events of ID 1121.
Here is a screen capture (sorry, it's in French):
Note that only the GUID of the rule is shown, not the full name (the list of GUID can be found in the reference).
Or if you prefer using Powershell:
Get-WinEvent -ProviderName "Microsoft-Windows-Windows Defender" | Where-Object { $_.Id -eq '1121' }
I have written a program in vb.net for in house use that connects to a Progress OpenEdge database. Now I'm having a really weird runtime problem.
I have a .exe file that runs on my local C: drive, the C: drive of the servers, from a certain network Location (but not other places on the network) just fine on at least two regular users. The problem is that when I submit it to my IT manager for review she gives it back and says it wont even run; on looking at the error, it seems to fail on the very first select query (which happens before the form finishes loading) Specifically, it ultimately boils down to the error below:
System.Data.Odbc.OdbcException: ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
now, certainly, I'm using data sources in visual studio and parameterized queries. So, yes, if it's trying to run it as straight SQL and not filling the parameters like it's supposed to, then there is a question mark in a number field. My question is: why does the same .exe, in the same place, run by a user with HIGHER privileges throw errors?
Are you initializing the integer variable with zero (0). The question mark in progress means unknown value.
If you are still running into a problem or haven't verified a solution yet, maybe check this KnowledgeBase article on SQL tracking out to make sure that the interpretation/execution of these statements is correct.
Providing that everything is the same with the SQL statements, the problem is most likely with the way the .exe is being run. There may be filling with an alpha character rather than numeric input depending on how the .exe is being run.
This isn't strictly a programming question, but hopefully someone here has the knowledge to help me.
Running Vista x64, the "Open File With" dialog takes forever to appear when trying to open a file with unknown type.
To be specific, the prompt giving the choice between "Use the web service to find the correct program" and "Select a program from a list of installed programs" appears immediately, but there is about a 10 second delay between pressing OK here and the next window (with a list of installed programs) appearing.
The same delay is present when I run "rundll32 shell32.dll,OpenAs_RunDLL" from a command line.
I'm guessing that this is not common behaviour, because I find it incredibly annoying, and I couldn't find any mention of it anywhere.
So..does anyone have any ideas what it might be? Or what I could do to try and find out?
VonC could be correct.
Read this article:
http://blogs.technet.com/markrussinovich/archive/2005/08/28/the-case-of-the-intermittent-and-annoying-explorer-hangs.aspx
You should use process explorer to watch the stack when you initiate the action. You should be able to tell what sort of operation is timing out.
Download process explorer here:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
You could check if you do not have have network connection declared (net use), or more generally any network paths which may be used by your list of program listed to "Open File With".
If a network path is unavailable, a 'timeout' delay can affect the GUI responsiveness, especially if that GUI must explore/list those paths.