-------------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...
Related
My question is a mix of a development and an administration question, but since it affects mainly developers and refers to a development tool (Access, VBA and the Form model), I am posting it here and hope that I don't get flamed. Having said this:
I have converted an Access 2010 x64 .adp project to Access 2016 .accdb, which was not too difficult. But now, whenever I am running code which references the UniqueTable property of a form, I am getting the following error:
Run time error 2455 You entered an expression that has an invalid reference to the property UniqueTable.
This is a known issue with Access 2013 and Access 2016; see here, for example.
Microsoft has made a fix - see here.
And here is the problem: A few days ago, I have installed Office 2016 x64. When trying to apply the fix mentioned above, I am only getting the following message:
There are no product affected by this package installed on this system.
Of course, I have double checked that I was using the right version (x64) of the patch. I have not yet tried to install Office 2016 x86 and apply the x86 version of the patch, though.
Did anybody manage to actually install this patch against the x64 version of Office 2016? According to Jim Conrad's statement (second to last post here), it cures the problem, but this doesn't help if we can't install it.
Well, the uniquie table setting really not of any use in Access (non adp). As far as I can tell, the setting tells (told) Access to use the PK from the source data table, and as a result should not effect anything of value I can think of here.
What I would do is open up the form(s) in design mode in the ADP project, and simply blank out the setting BEFORE you import the table into the accDB. The issue is you can't get at and remove this non need setting in the accDB, but it persists when you copy from the ADP.
So, simply blank out the uniqueTable setting in the ADP and then import the tables. You could also write a loop, and do all of the forms in one shot before you import them into access (so, I guess working on a copy would make sense).
So the issue here is that the setting persists when you copy the table into the accDB, but THEN you can't get at, or change, or remove this setting since it is not exposed via code, or the property sheet.
So, the simple solution here is remove the setting in the ADP application before you import the forms into the accDB.
I have an Access, 2007 – 2016, accdb database on my Toshiba Satellite Pro running Windows 7 32 bit. I am using MS Office 365.
The database that opens at its home page, but any attempt to open a table, form or module brings up this message:
“The database cannot be opened because the VBA project contained in it cannot be read…”
I have 2 backups of this database, but they do the same thing.
I have read several posts on the internet that indicate that the problem can be solved by decompiling the database.
I have tried the VBS Script solution contained in:
How does one decompile and recompile a database application?
However, it does not get to decompile as the same message displays when the .vbs file opens the database.
I have read some other posts that indicate a problem with a VBA7 file, but these refer to Access 2010, so I do not know if they also apply to me. I have VBA7.1 by the way.
Attempts to decompile through the Command Prompt has its own problems that seem to be associated with file names with spaces.
So, I’m stuck. Any help would be much appreciated
I ran into this same error at work, Have you tried shift-clicking and opening? I know that seems obvious, What I did, was I got the DB open in safe mode, and opened up a module in the vba editor, and tried to fight the problematic code, if anything you could delete all your modules after copying them into a notepad.
I also right clicked and restored previous versions from windows, I am not sure if you have tried this when you say you have to back ups, but i was unaware of this fix and i luckily had a version from last week that fixed my issue.
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.
Last week I was modifying portions of two modules in an access 2010 db when the program crashed, and would crash every time I tried opening up the db thereafter. I was able to create a new database and import the tables and queries from the corrupted one, but when I tried to import the forms/macros/modules the new database would start crashing also. I keep daily backups, but ended up losing several hours worth of work. This happened twice last week, each time MS Access would crash without warning and the VBA was unrecoverable.
The functionality works as intended until the db crashes seemingly at some unknown point. There must be some sort of issue with my VBA code, since this only started happening when I started modifying the module last week, but I can't pinpoint it since the crashes actually occurred when nothing was being executed. Ie during save.
Does anyone know if it's possible to export the VBA out of access without exporting it to another database? Ie export it without having to use MS Access to do so. On a related note, has anyone created a library that exports query definitions, table schema, and all VBA to text files that I could drop them into source control?
Thanks.
In addition to the method suggested by #Remou, you could try the SaveAsText method to save a code module to a text file.
Application.SaveAsText acModule, "Module1", "D:\Access\Module1.txt"
However, that doesn't satisfy your desire to do it without using Access.
Try a decompile operation on the chance your project includes saved compiled code which has been corrupted. You can find detailed instructions for decompile in the 2 answers to this Stack Overflow question: ms-access: HOW TO decompile and recompile
After decompile, make sure all your modules include Option Explicit in their Declarations sections. Check the project's references, and fix any that are broken (missing). Then run Debug->Compile from the VB editor's main menu to verify your code compiles without error.
Those steps are the best I can offer to reduce potential for continued corruption problems.
For integrating source control with Access, start with this selection of related Stack Overflow threads: site:stackoverflow.com ms-access version control
Folks
We're having the same problem. There is a bug in SP1 that causes it. If you keep opening the database, you'll finally end up with a backup that works - rename the old one BROKEN and remove the _backup from the new database, and you are oky till your next bit of development. Our IT guys (Microsoft Gold Partners) are looking at a fix reported on http://answers.microsoft.com/en-us/office/forum/office_2010-access/access-2010-sp1-you-receive-random-crashes-in/d2bf6175-075a-4a12-a2b1-f55d40af271b
I may go take a look at decompile/recompile however as some of our database have come all the way up from Access 97, to 2000, 2003 and now as mdb/2003 file format still, running under 2010. Having said that, converting to accdb/2007 seems even worse!