Fritz Paul
asked on
Experience with VBA code that changes unexplicably?
Below are two screen copies of code in a front end database. The first one is in the original which I created a week ago and it is still like that. The second is from a copy which a user pasted on her desktop (as usual) and this morning she experienced an error due to two "End Sub" 's after each other.
So some code lines went missing and some additional empty lines appeared as commented on the second picture.
She made a new copy from the original and of course it works now.
I've never had an experience like this. Do you think there is some virus or could something else non-human be the cause?
I trust the user and her performance depends on the software, so I cannot see any reason that she would sabotage the code.
original code
altered code
So some code lines went missing and some additional empty lines appeared as commented on the second picture.
She made a new copy from the original and of course it works now.
I've never had an experience like this. Do you think there is some virus or could something else non-human be the cause?
I trust the user and her performance depends on the software, so I cannot see any reason that she would sabotage the code.
original code
altered code
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
We do also find since end October, that data records in the back end gets corrupted on a too regular basis (more or less weekly). At that time we had a ransomware attack. We recovered from backups, but these corruptions are appearing more or less weekly. Tables are loosing their Primary keys and required fields loose their require status. That is why I am thinking of something other than user error.
What do you think?
What do you think?
I don't think the issues are related.
Do you have users on different versions of office/access using the same backend? I have heard it can cause issues, but have not myself experienced it.
Do you have a system in place that prevents anyone with an outdated version of the frontend using the system?
Do you have users on different versions of office/access using the same backend? I have heard it can cause issues, but have not myself experienced it.
Do you have a system in place that prevents anyone with an outdated version of the frontend using the system?
ASKER
Anders, yes, we have users with 2007, 2010, 2014 and 2016 Front ends and the back end is 2007. Nobody has earlier than 2007 front end.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks guys,
The main reason why I do not supply compiled versions is because the users have different versions of office, which means that the references to each different version has to be set in the VBA editor. That alone is a risk and I believe the maintenance is now becoming more expensive than an overall upgrade.
Another issue is that I do not have password protection on the front or back end, because up to now we believed that we can trust everybody. However I think people are becoming suspicious of each other. So to protect everyone, including myself it is better to build in maximum security.
The main reason why I do not supply compiled versions is because the users have different versions of office, which means that the references to each different version has to be set in the VBA editor. That alone is a risk and I believe the maintenance is now becoming more expensive than an overall upgrade.
Another issue is that I do not have password protection on the front or back end, because up to now we believed that we can trust everybody. However I think people are becoming suspicious of each other. So to protect everyone, including myself it is better to build in maximum security.
The main reason why I do not supply compiled versions is because the users have different versions of office, which means that the references to each different version has to be set in the VBA editor.That's something that you can resolve fairly easily by following good development methods.
Always develop in a "Lowest Common Denominator" environment. If users are running both 2010 and 2013 versions of Office, then you must develop in Access 2010, with Office 2010 on your development machine. Access can upgrade references (even in mde files) but cannot downgrade them.
You can also use Late Binding to avoid these types of issues.
And I also agree that you should be providing users a compiled file.