OK so this is kind of a general question here. We run an ASP/C# Site that's fed by a SQL 2008 R2 database.
Our data entry takes place using Microsoft Access 2007 and feeds to a SQL 2008 R2 instance.
Our data entry forms (all .adp) are generally simple, but we randomly run into problems where I'll post a change to the DB (we have a script that runs at night and will archive our old DB versions in the form of "DB_NAME.adp03122012" and keeps the newest revision as "DB_NAME.adp". This way, our data entry team will just need to click on a network shortcut to access the Access forms.
What we're running into is non-reproducible errors of varying types on random machines.
Example, I make a simple search that has a combo box and a search button. You select the item you want to search for and it updates the record source to search for that PK/FK. It works fine on my developer box. It works fine on certain end-user boxes. But on others, it throws a run-time error:
"Run-time error 2467: The expression you entered refers to an object
that is closed or doesn't exist".
Now the error itself isn't the focus of this. It's not being able to reproduce it. I tried running it on another box that has the same hardware specs as the offending box and it ran fine, no errors, no nothing.
I'm at an absolute loss as to why this is happening. I don't think the error is actually related to my VB code or to our databases, as it's working fine on some computers and isn't working on others. It's almost as if the code isn't propagating properly to specific boxes.
Has anybody else dealt with this before?
I feel somewhat foolish, but our Network Admin hadn't propagated Windows updates to all of our end user boxes.
The advice that Remou and mwolfe02 gave was valid and helpful, and likely would've helped had I been informed that the computers in question needed updates.
Thank you for reading and offering comments and help.
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)
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 I started with the Access contact database template and have been building up from there. There is a functionality in which by clicking on the ID number in the Contact List, it should call up the form to edit the details. I have made no changes to this code, and have even tried recopying it from the template from scratch.
However I am getting the error "A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control." It is telling me to restart the OLE server and try the operation again.
I have an old version of the database saved, and it runs fine over there. It just is something within my code here.
Any guidance would be appreciated.
All of solutions I found online was not working for me.
Found that only rebuilding damaged form from scratch help me to solve this issue.
W10, Office 2016.
I have ran into this error three times in my database. Each time to fix it I simply just open a new blank project and import everything from your old project into your new project.
This might sound like a large undertaking basically you just go into the new project and select "Import Access Database". Then just run through the wizard selecting everything in your current database. Click okay and let it run for a few minutes.
This has fixed it for me every time I have run into your error. I suspect it is just something to do with corruption.
My programs also run into this error sometimes.
I have recently noticed that the error most often occurs on UNBOUND forms (forms without a RECORDSOURCE).
What I have done most recently for these forms is the following:
Add "some" table (I usually take a Config table with just one record) as the RecordSource.
Compile the program code (this usually goes well, even before the fix!).
Save the form
Open the form. This should work fine now!
Remove the form's RecordSource, recompile and save again.
The form should still work fine!
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.
I am trying to print a report that contains a bar graph using the report viewer, but running into an error. My reporting server is running SQL Server 2005 Reporting Services SP3 on Windows Server 2003 SP2.
Here are some steps that will reproduce the problem (at least for me)...
On a clean machine, I open up the
report, and it displays fine.
I then click the print button, and I
am prompted to install the
RSClientPrint ActiveX control. The
control downloads and installs fine.
I then click the print button again,
and the print dialog appears.
I select a printer, and click "OK".
A message box appears that has the
following text (including the
spelling error)...
An error occured during printing.
(0x80004005)
Any other report I try to print works fine. The only difference between this report and the other ones is that it contains a bar graph. If I remove the graph from the report, redeploy it, and then re-run it, it prints without getting that error.
As far as I know, it is not isolated to a specific machine. It happens to every customer I have talked to, and a variety of machines here in the office.
Has anyone seen anything like this? I have seen similar posts on the web suggesting to uninstall video drivers on the reporting server (thinking the GDI dlls have become corrupt ), install service packs, etc. I have tried every suggestion, but haven't found a good solution yet.
Thanks.
I ended up having to use a paid Microsoft incident on this, but it is resolved now. The issue was that I had a matrix in my report that had dynamic columns. Depending on exactly which date range you picked, the report could have n number of columns. In my case, when a date range was chosen that produced three or more of these dynamic columns, it would cause the matrix to become too large and run outside of the margins of the report.
The report would run and display fine with the matrix being too large, but the incredibly non-descriptive error would display whenever the report was printed or exported.
I resolved the issue by reducing the size of other columns and the overall font size in the report. This prevents the matrix from running off the page in the case of date ranges that produce three dynamic columns. It doesn't solve it in the general case (four or more columns will make it fail), but is good enough for my current purposes.
Microsoft didn't have a fix for the general case (such as a way to make the matrix fixed width).
I figured I should answer this in case anyone else runs across it.
-David