I am a coop student at a factory and I was developing a VBA program in excel for the operators to use for data collection. The program works perfectly on my bosses and my user account, but is throwing runtime errors when the operators try to use it; specifically, it is throwing a runtime error 13 (type mismatch) when I know the data is correctly entered.
Something as simple as Msgbox Cdec("26.1"), or Msgbox Cdbl("26.1") is throwing the mismatch error on the operators account, but it runs perfectly on my account (on the same computer). I initially thought it could have been to keyboard settings/language settings so I tried playing with the settings while entering data, but nothing changed. I checked to make sure that all of the same libraries were being referenced in the excel options.
I am completely at a loss and don't know where this problem is coming from. I would appreciate any suggestions.
I have figured out what the issue is. Because I reside in Ottawa, Canada which is bilingual, some of the operators had French regional settings. This caused them to use a comma instead of a period for a decimal point. By simply changing this property in the windows "regional settings", I was able to resolve the problem.
Related
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 an Excel addin, developed in VBA, deployed on the network.
The addin reads from an Oracle database, and pastes tables in a new worksheet, which will also contain a button (triangle shape) to refresh the table.
Everything works great, but I must protect code with password.
When i do, the following error appears on some machines:
Compile error in hidden module: Main.
This error commonly occurs when code is incompatible with the version, platform, or architecture of this application.
Although it compiles perfectly when unlocked.
On other machines it requires VBA password on close, even though i have nothing of the sort defined under close event.
I am hoping to secure my code, without running into above problems.
Any suggestions are appreciated.
I know of two situations in which this error occurs:
1: 32bit vs. 64bit issues (already mentioned in the comments). If you've developed a 32bit addin and try to deploy/use it within a 64bit Excel, then your quoted error message will appear.
2: Missing references.
I think the second option is more likely to be the cause of the problem, because usually all client PCs in a company will have the identical version of MS Office installed and this error occurs only on some machines.
So I suggest to check your references. In the VBA-Editor (Alt+F11) go to tools --> references and note down any ticked modules. Then compare this to a client where the error is occuring (go to client PC and repeat the procedure).
If the ticked modules don't match between development and client PC, this is most likely the cause of this issue. You might also encounter modules with a "MISSING" written in front of their name on the client PC. In this case, remove the tick from the missing module and try to execute your addin.
If it works flawlessly you should be good to go, if not you'll have to manually install the missing modules on the clients PC.
Hope this will help you.
I am designing my first database from the ground up and I have learned a lot in the last few weeks. One thing that has been eating at me though is that on my login page I have a simple unbound text box with its control source as =Date().
This works perfectly well on the computer I use most days, but any other computer in the facility I am working out of displays #NAME? instead of the date.
I have tried changing to =Now() and it works fine on all computers. Apparently only =Date() has issues. If the fields control source is changed back to =Date() I am informed that The function you entered can't be used in this expression.
I have checked the MS-Access versions and tried on a machines with and without access.
I really need Date() to work because it is used elsewhere in more vital areas of my code and I may not be able to use Now() in its place. Any ideas as to why this may not work on any PC besides my own?
Date() is controlled by the Visual Basic For Applications X.XX reference. Make sure the reference is installed and any competing references are removed.
To do this, open the VBA window and go to Tools --> References and ensure the proper one is checked.
I suspect the issue is user's region and language settings for the date. I noticed this when I changed computers and my files wouldn't save anymore due to the slashes in the date. You should try the format() function so that your dates always have the same format and can be used across machines independent of the user's settings.
Sub Foo()
Debug.Print Date
Debug.Print format(Date, "yyyy-mm-dd")
End Sub
Output
7/23/2015
2015-07-23
I have added my macro to a already existing excel file with macros (build on lower version of excel). It is working fine on my system as well as other systems with same excel version. But when the excel file is opened in other versions, it either crashes or gives error messages like unexpected error occurred(32809)/ compile error. I am using Excel 2010 14.0.7143.500. Can any body tell me how to resolve this issue?
The Telemetry Log displays some simple information about the recorded events. Each record displayed in the Telemetry Log contains a title and lists the severity of the event displayed. For errors, the records also include a description of the error together with steps to address the issue. Keep in mind that not all of the records displayed represent errors caused by Office solutions; the Telemetry Log also shows when solutions and files are loaded or closed successfully.
For example, the issue titled "OM Hidden: Comment.Initial Property" appears if a solution or macro-enabled file opened in Word 2013 attempts to get the initials of a commenter who is associated with a comment. Word 2013 features an improved commenting experience that does not display commenter initials by default. The APIs associated with the older commenting model have been hidden in the Word 2013 object model but remain available for backwards-compatibility. The "OM Hidden: Comment.Initial" issue in the indicates the file that attempted to use the API, the application that raised the event (Word 2013), the time and date of the event, and short description about the error and how to fix it.
I am having serious problems with the Microsoft Windows Common Controls 6.0 SP6 library in Access. I have a number of scripts which were working fine before the weekend, but which fail lately on multiple different computers when they encounter the StrConv function. Here's a low-down on what's been going on:
Previously, all was working fine. On the afternoon of Friday the 20th (4 days ago), I began encountering some odd messages when I moused over a progress bar ActiveX control I had on one of my forms. This happened on the MouseMove, MouseDown, MouseUp and MouseClick events at least; the message reported was "The expression [MouseMove] you entered as the event property setting produced the following error: There was an error loading an ActiveX control on one of your forms or reports." I had registered none of the events mentioned on this control. Scripts in general were still working at this point.
Yesterday (after the weekend), I found that scripts I had written no longer worked. When encountering the StrConv function (which I was using to convert a string to uppercase), the VBA editor brought up an error message saying "Compile error: Can't find project or library." This function I'd imagine is quite a core part of the VBA language, but the only missing library I could find under Tools->References was "Microsoft Windows Common Controls 6.0 (SP6)". The missing file was listed as C:\Windows\system32\MSCOMCTL.OCX but this was present on the machine anyway. Browsing to it in the references dialogue made no difference.
Since then I have tried installing various different Microsoft Visual Basic redistributions, have followed the instructions at http://www.fmsinc.com/MicrosoftAccess/controls/mscomctl/, have phoned our company's tech support and have tried a system restore to a point where the scripts functioned previously, but nothing has worked. The database I am using resides in a networked folder on a server but the MS Access applications are local to the workstations.
Is there any way to resolve this issue?
Simply open one of the forms giving you trouble in Design View. Insert a new ActiveX object control in the form and save. Load the forms again. Hopefully this solves the problem. You can then safely delete the added control.