I have several ms access databases that contain many lines of VBA code. All this worked fine up until a few months ago when network security software called Cylance was installed. This Cylance prevents many different types scripts and programs from running. Cylance uses something called a 'Whitelist' folder from which you should be able execute code that is known to be safe.
In the Whitelist folder I have database, when I try to run code that I know worked a few months ago I get a runtime error 13 Type Mismatch. However there is no mismatch and this code executed fine in the past.
Is anybody else working in Cylance environment? Have you had Error 13 Type Mismatch? How to fix it?
The main thing I've tried is working from the Whitelist folder, I don't know what else to try.
I tested Cylance and I had to uninstall it because it had too many false positives. Not even with VBA code. It was blocking legitimate applications that we needed. I could whitelist an application but then I needed to whitelist it again every time the application was updated. If you are developing software you would have the same problem. You would have to whitelist every build. I can see how this would cripple your Access development. Cylance keeps you safe from VBA attacks in a way that other AV solutions do not but the trade off is that it also blocks VBA code that you know is safe. Open a ticket with their support team. Good luck.
Related
I have an access front-end that connects to SQL Server tables and works fine. When I compile it into an accde file however, I get various errors when closing the DB. The errors seem to indicate that the program is still looking for a table or the value of a global variable. There is a routine in the Form_Close() event of a hidden form that Deletes all the links to the SQL Server back-end. So, how can I debug an already compiled access database? Why does the compiled DB behave differently than the uncompiled (accdb) version?
You need to trap errors using On error goto LabelName or if you don't care about errors you should use On error resume next on top of your code. You should still post your code to get more accurate help.
Are you talking about the same computer, or different computer?
The compiled accDE are VERY sensitive to being executed on a different machine (even the same version). The reason for this is that the compiled accDE takes on your current office release version.
In terms of global variables, and error handling?
accDE's are the BEST choice, since un-handled errors does not re-set local, or even global variables. In effect, a accDE runs like a un-stoppable freight train.
if your accDB (un-compiled) works and runs fine on your computer, then I have NEVER seen a case in which the accDE does not run, and in fact run better and behavies far more ro-bust.
So, no, you can't debug the accDE, but you can the accDB on the SAME computer.
If you are running the accDE on a different computer, then you left out a massive, huge and SPECTUALAR bit of information in your post.
If you ARE running the accDE on the same computer (that you created it with), then about the only possible is that the accDE file extension is using a different version of access to run with. This is rare - I would thus from the control panel, applications and features find your version of access and right click and do a repair on your office install.
The issue of patch version of office/access is VERY significant here. The reason of course is that if you deploy the accDB, it will often work because access can (and does) detect that the current version (even SP/patch/update) level of Access is different, then it can re-compile the code on the fly (because the accDB has the source code). The accDE does not, and thus it can't re-compile. However, I still STRONG suggest you deploy the accDE and resolve the SP/patch level issue since a accDE is oh so much more reliable in its operations compared to un-compiled accDB's.
I would be rather stunned if you are experiencing this issue on the same computer running the accDB and that computer is then used to create the accDE. If this is the actual case, then I would create a new blank accDB, and import everything from the old accDB, and then ensure it can compile the code (from IDE debug->compile). If the app compiles, then create the accDE, and it should work just fine. So, if this is same machine, then your accDB is damaged or corrupted. As I stated, create a new one, import everything from old, and create your accDE from that. It will work, and I never seen a case in which a accDB works, and a accDE does not work (on same machine).
1st thing to do is to decompile your application ...just Google Ms Access Decompile.
When you perform the Decompile and try to compile is almost certain that you will find some "forgotten" mistakes.
2nd if 1st fails its time to implement a robust logging system...based on text file writing, in order to avoid dependencies just work low : https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/freefile-function.
If it still fails post back with more info.
Quick overview: I develop Excel Macros for a firm. The Macros are used in a daily basis for more than 200 workers. These 200 workers connect the Local Machine to a common server (there actually 3 servers) and run the Macros from there.
Problem: Today in the morning some of these Macros (different Macros) starting crashing Excel with the tipical message "Excel has stopped working". These Macros (which I didn't update) run every day without a problem. Today, just like magic, they starting crashing for different lines of code which only common denominator is that they use a lot of resources.
Ex:
sh.UsedRange.Value = sh.UsedRange.Value (the UseRange is alcually a pretty small range)
Application.Calculate
wb.Sheet1.Move
I understand these are functions that take a lot of memory but still they have been working for months without a problem until today. I know this could be more like IT kind of problem but since I'm trying to solve this issue, I thought maybe one of you either had this problem before or know a possible cause (like a Windows update).
IT already reinstalled Excel in all the servers that we use for remote connection but the problem persists.
Any Idea?
Thanks a lot,
Ok, here is what happened in case you guys see this problem in the future:
Everything is Microsoft fault's. They launched an update to fix some Excel bugs and instead of fixing them, the server that automatic updated their versions, got really messed up. This updated was launched on Mar/14/2017 (2 days Ago).
I made some research and this sounded very weird to me. They launched an update to fix Excel 2010 bugs and now my Macros are breaking without changing the code? It had to be that and there it was.
Here's the Log:
https://support.microsoft.com/en-us/help/3178690/ms17-014-description-of-the-security-update-for-excel-2010-march-14-20
Just keep your head up if you have Automatic Updates on in your computer and see problems like these happening. In case you find that's the problem, just remove the update from your Excel.
Regards,
I am currently running into a similar issue with an Excel VB script utilizing the Today() function. The script freezes up and becomes unresponsive when the date is 03/17/17, but if I change the system date to 03/16/17, everything works great.
It appears that there were a number of Microsoft Office Updates on 03/16/17, so I am going to try and remove them one by one and see if that fixes the issue. I'm starting out with the Security Update for excel, KB3178690.
Update -- confirmed, removing Microsoft Security Update for Excel KB3178690 fixes the crashing issue related to the date function after 3/17/17. Probably some deeper reason to this, such as activeX forms or something (of which I don't believe this script utilizes), but at any rate it's working now.
My laptop ran the latest windows 7 updates last night and since then all my macros have stopped working. I have had to roll my laptop back to a point before last nights updates and everything is now working fine again. Think there is a major issue with the latest Microsoft update releases.
For my customer i had to do a change in a visual basic 6 application running on a windows xp computer.
It's nothing special, just communicating with a plc and functions as a user interface.
My changes work absolute perfect in developer environment(IDE), but when i create the exe it crashes when opening some forms or pressing some buttons. Some stuff works, and some stuff crashes.
Compiler in develop doesn't give any errors even after full compile!
I found some "bugs" by iterating the code and this really is just deleting some variables. (that already existed + It isn't a programmable error) The compiler doesn't give an error, just the exe crashes on it.
An example from bug that crashed:
sub On form_load()
Some code
Global_String_Variabel = "Something"
some code
End sub
By deleting the global string variable just in this form, it didn't crash any more.
It's weird because this peace of code already existed, works perfectly fine in develop but not in .exe
Does somebody have any idea why this could happen?
If I understand your question correctly, the program runs on your development machine both in IDE and compiled in both states, with the string assign and without, yet works only without on the client's machine. Something like this happened to me many years ago, and while it may not be your problem, you might at least be able to rule it out. The client may have a virus scanner that erroneously thinks that a segment of your code is malware. Just adding another line like x = x or something else benign can sometimes fix it.
You may also need to look further into other differences, like other things they have/run that you don't.
Not that it should matter but are you declaring the variable somewhere and using Option Explicit?
My firm's Access database has been having some serious problems recently. The errors we're getting seem like they indicate corruption -- here are the most common:
Error accessing file. Network connection may have been lost.
There was an error compiling this function.
No error, Access just crashes completely.
I've noticed that these errors only happen with a compiled database. If I decompile it, it works fine. If I take an uncompiled database and compile it, it works fine -- until the next time I try to open it. It appears that compiling the database into a .ACCDE file solves the problem, which is what I've been doing, but one person has reported that the issue returned for her, which has me very nervous.
I've tried exporting all of the objects in the database to text, starting with a brand new database, and importing them all again, but that doesn't solve the problem. Once I import all of the objects into the clean database, the problem comes back.
One last point that seems be related, but I don't understand how. The problem started right around the time that I added some class modules to the database. These class modules use the VBA Implements keyword, in an effort to clean up my code by introducing some polymorphism. I don't know why this would cause the problem, but the timing seems to indicate a relationship.
I've been searching for an explanation, but haven't found one yet. Does anyone have any suggestions?
EDIT: The database includes a few references in addition to the standard ones:
Microsoft ActiveX Data Objects 2.8
Microsoft Office 12.0
Microsoft Scripting Runtime
Microsoft VBScript Regular Expressions 5.5
Some of the things I do and use when debugging Access:
Test my app in a number of VM. You can use HyperV on Win8, VMWare or VirtualBox to set up various controlled test environments, like testing on WinXP, Win7, Win8, 32bit or 64 bits, just anything that matches the range of OS and bitness of your users.
I use vbWatchDog, a clever utility that only adds a few classes to your application (no external dependency) and allows you to trap errors at high level, and show you exactly where they happen. This is invaluable to catch and record strange errors, especially in the field.
If the issue appears isolated to one or a few users only, I would try to find out what is special about their config. If nothing seems out of place, I would completely unsintall all Office component and re-install it after scrubbing the registry for dangling keys and removing all traces of folders from the old install.
If your users do not need a complete version of Access, just use the free Access Runtime on their machine.
Make sure that you are using consistent versions of Access throughout: if you are using Access 2007, make sure your dev machine is also using that version and that all other users are also only using that version and that no components from Access 2010/2013 are present.
Try to ascertain if the crash is always happening around the same user-actions. I use a simple log file that I write to when a debugging flag is set. The log file is a simple text file that I open/write to/close everytime I log something (I don't keep it open to make sure the data is flushed to the file, otherwise when Access crashes, you may only have old data in the log file as the new one may still be in the buffer). Things I log are, for instance, sensitive function entry/exit, SQL queries that I execute from code, form open/close, etc.
As a generality, make sure your app compiles without issue (I mean when doing Debug > Compile from the IDE). Any issue at this stage must be solved.
Make absolutely sure you close all open recordsets, preferrably followed by setting their variables to Nothing. VBA is not as sensitive as it used to be about dangling references, but I found it good practice, especially when you cannot be absolutely sure that these references will be freed (especially when doing stuff at Module-level or Class-level for instance, where the scope may be longer-lived than expected).
Similarly, make sure you properly destroy any COM object you create in your classes (and subs/functions. The Class_Terminate destructor must explicitly clean up all. This is also valid when closing forms if you created COM objects (you mentioned using ADOX, scripting objects and regex). In general keeping track of created objects is paramount: make sure you explicitly free all your objects by resetting them (for instance using RemoveAll on a dictionary, then assigning their reference to Nothing.
Do not over-use On Error Resume or On Error Goto. I almost never use these except when absolutely necessary to recover from otherwise undetectable errors. Using these error trapping constructs can hide a lot of errors that would otherwise show you that something is wrong with your code. I prefer to program defensively than having to handle exceptions.
For testing, disable your error trapping to see if it isn't hiding the cause of your crashes.
Make sure that the front-end is local to the user machine, You mention they get their individual front-end from the network but I'm not sure if they run it from there or if it it copied on their local machine. At any rate, it should be local not on a remote folder.
You mention using SQL Server as a backend. Try to trace all the queries being executed. It's possible that the issue comes from communication with SQL Server, a corrupt driver, a security issue that prevents some queries from being run, a query returning unexpected data, etc. Watch the log files and event log on the server closely for strange errors, especially if they involve security.
Speaking of event log, look for the trace of the crash in the event log of your users. There may be information there, however cryptic.
If you use custom ribbon actions, make sure thy are not causing issues. I had strange problems over time with the ribbon. Log all all function calls made by the ribbon.
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?