I have inherited a system which was developed in InfoPath 2010 but saved in 2003 format.
A former colleague was asked if he would make changes to the forms. Last week, I was approached to make the same changes. When I opened the form in edit mode I noted that the changes were already saved. I tried making a couple more changes and both saved and deployed them. When I opened the form again, all changes were lost.
In addition, I tried to extract data from multiple forms at once but this has stopped working too and is now only letting me extract data from one form at a time.
It is only this past few weeks that this has been happening. Prior to that, we were problem free.
Has anyone come across this before and, if so, how did you fix the problem.
Related
A couple of weeks ago, our Access application suddenly began to fail mysteriously. Comboboxes on random forms would not fill with rows when recordsources were set. These include forms that have not changed in years. Stepping through the code in the debugger always results in a successful outcome. Trying multiple times consecutively would occasionally work. One or two computers still work reliably, though these have a source control addon called Ivercy installed. When you run the deployed version (without the addon active) these machines show the same unreliability.
Last week, we found more issues including some forms and reports that would not populate on initial opening. Reselecting the same filter date (or other rowsource changes) once the form is open brings up the expected set of rows. Again, loading the form while stepping through the code always works.
These behaviours lead me to believe there is some sort of fault that has been introduced in a recent Access update. Has anyone else seen this kind of problem?
One instance of this issue occurs on a very simple, one page report that has no user code in it at all. I would have been willing to believe that we had been doing something systematically wrong in our code, but this code-less report seems to suggest otherwise.
My machine (which exhibits the problem) is using Microsoft 365 Apps for enterprise
Version 2105 (Build 14026.20308 Click-to-Run)
-------------UPDATE-------------
By coincidence I actually found an old post, posted a year ago, by myself with sort of the same problem (totally forgot about it). I suddenly remembered that there was a problem with a reference not being there. Back then I changed everything to late-binding. About a half year ago I created my own COM add-in in C# for my access application, I register this COM object with a script but at this specific user this didn't work. When turning off the specific reference, everything worked again. Conclusion: the bugs / errors were caused by the broken / missing reference...
----------------------------------------------
In the category of weird access problems I have another problem.
In my access 2013 application all the comboboxes don't autocomplete any longer on 1 specific computer. The items are in the list but autocomplete just doesn't work anymore. I have read several other related problems but all those solutions don't work. I have checked / tried the following:
Repaired the database
use the DISTINCT keyword in my rowsource (ANSI-92 issue related)
set the auto-expand property to yes
The weird thing is that other users use the exact same file (it is being copied to local) and at their computers it does work..
The file is of type accde. A week ago I had the same problem and I tried to open the same file but instead of opening the accde version I opened the accdb version at this specific users computer and that seemed to work (autocomplete was working again). This worked for about a week but now it is someway corrupted again (I did change the file however and deployed it again recently so that might have to do something with it). '
Besides the combobox autocomplete problem, the same user has also the problem that one specific form doesn't open any longer (again, at the other users it just opens fine), the error is 2467 and it errors on setting the alloweditions of the subform through code. Though it is just weird that this don't causes errors on the other computers so I suspect it is related to the same 'bug' as with the autocomplete.
Anyone experienced the same problems?
Some additional information:
the accdb file is coded /created in access 2013
the users are opening the accde file in access 2013 runtime, the user where the file seems to be corrupted opens the accdb file in the full version of access 2016 (the temporary solution up till now).
The access application uses SQL Server 2012 as back-end.
Fixed it!
By coincidence I actually found an old post, posted a year ago, by myself with sort of the same problem (totally forgot about it). I suddenly remembered that there was a problem with a reference not being there. Back then I changed everything to late-binding. About a half year ago I created my own COM add-in in C# for my access application, I register this COM object with a script but at this specific user this didn't work. When turning off the specific reference, everything worked again. Conclusion: the bugs / errors were caused by the broken / missing reference...
I built and successfully split an Access 2013 db. The front end worked fine for months up until I last used it a few months ago. I recently went to open the front end but the Access window was frozen whereby everything (e.g., navigation pane, menus, controls, right click, etc.) was disabled, including the window control buttons to minimize, expand and close. The only way to close the view was to right click the Access icon in the task bar or 'ctrl-alt-delete' to open task manager and force close the application. I was met w/ similar results when attempting to open other versions of the linked front end; however, I can successfully open the back end and other Access db files that don't contain linked tables. When I get the 'frozen' screen I can see my linked tables and other db objects in the navigation pane, but the pop-up login form does not display and the entire window behaves like it is inactive, similar to how it behaves when selecting items behind the active login form.
To confuse matters even worse, I have one user (User 1) who has the same user permissions as me who does not experience any of the problems I described above and can work within the front end as expected; in fact, he and I are the only active users as we are still in the developmental phase of our project. One other layer of complexity, he tried to open the file w/ his network profile from my computer and ran into the same problems. We have one other user who we've since tested this problem with and she experiences the same issues as me on both her laptop and PC.
So, I thought maybe it had to do with the 32-bit version I unknowingly had installed when my OS was re-installed last month since User 1 had the 64-bit version which could explain why he couldn't open from my computer. BUT, I still experienced the same issues after re-installing the 64-bit version on my computer. I'm at a loss on where/how to proceed from here and my IT guys have done all they can to troubleshoot my problem as they are not familiar w/ Access and aren't much help at this point.
Anyone run into this problem before? Thoughts or possible solutions? Any and all help would be greatly appreciated, thank you.
So, I disabled the code that prompted the login form and I was able to open the file. Based on User 1's experience, we determined that he hadn't installed updates since I was last able to open the file. As a result, we determined that an update I installed was not compatible w/ the aforementioned code resulting in the problems I described in my original post. I will re-create the code that drives the form's login and keep an uncoded version as back-up in case we experience similar issues in future updates so that we can troubleshoot from within the db rather than be locked out as we were.
I hardly dare bring up this topic because what is happening is so extremely strange - but I'll try anyway.
I have a large Access DB for a customer. One of the forms in the front end has a series of subforms. Until recently, everything was working well.
Now, when a new version of the front end is sent to the customer (I tried Team Drive as well as WeTranser) this results in one of the subforms being changed to a different form. This form is also in the database but is by no means linked to the main form in question.
I have tested this several times: The version on my PC is still working perfectly. The version that the customer sent back to me according to my request has the wrong subform in it.
We are all working on Access 2010 with an Access 2000 format MDB. The reason for this is that the Backend needs replication.
Does anybody have a clue on how or why this could be happening? Thanks in advance.
Found a solution myself after testing together with the customer.
Copied the file via USB stick this time. The copied file was OK on the destination system. Opened file pressing shift button so no programs would run. Everything was still OK. Then opened the file in the usual way. The start form realized that the paths had changed and relinked all the tables. Except for the start form, no other forms are involved in this operation. After that, the subform had changed to a different form.
Solution (rather: Workaround): Changed the name of the subform that replaced the correct subform. After that, everything went well.
The change of the subform only occurred during the relink routine. If the subform was changed to the correct one manually after relinking, it remained correct.
Reasons? Has Microsoft released updates to MS Access recently? We'll probably never know.
So currently my boss and I are the two employees that work on our company's access database. I just got Office 2013 on my computer and he is will working with 2010. We have ran into some inexplicable bugs with the database.
Most of these can be fixed by just copying an old version of a form or report into the database when it fails; however, it is quite disconcerting when we spend hours trying to discover why something is wrong and are able to fix it without explaining why.
Most of the issues so far have occurred when I am using the db in Access 2013. So far the issues have been:
Access occasionally crashes and restarts when I am working in the VB code
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile erro. To further explain the "bugging out", the form usually contains about 2000 separate forms that you can search through, but when it bugs out it will only show one blank form. At first I panicked thinking all the table's data was gone, but nothing changed the table
There have been other hiccups, but nothing noteworthy besides these two
I guess my question is if anyone else has had issues along these lines, or if they knew of any other known issues. I tried to research errors people have been having, but I couldn't find anything besides Microsoft's official release of what features were being deleted.
As always, thanks in advance!
Your system should be split into two files. FE(front end) containing all forms, queries, code, etc., linked to the BE. BE(back end) containing the data tables only.
Maintain a development copy of the FE that is only used for making modifications.
Each user should have their own copy of the FE on their local machine. If you don't know how to split, just search for it as there are plenty of instructions out there.
I have 2010, but I worked with a consultant who worked on the same project in 2013. I too, saw some behavior that looked like version related bugs, but nothing definite.
Responding to your list:
Access occasionally crashes and restarts when I am working in the VB code -- This has happened to me in every version of Access I have used, from 97 to 2010.
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile error... -- If the compile error is severe enough to lose project state, this is not surprising.
Recommendations:
Decompile your application front-end occasionally, especially when 'weird' errors show up. See this SO link: automating decompile / recompile in ms-access
Compact & Repair at least daily while developing your application
Backup! Do this at least for every significant revision. Sometimes, the Access front-end will become so corrupt that it trashes all of your work. When this happens, nothing is recoverable.