Access 2010 Subform not loading for one user - ms-access

Recently, my team's Microsoft Access databases have been migrated from Access 2003 to 2010. Obviously that causes a many problems, but we got most of them figured out. There is one problem, however, that I can't seem to fix.
Many people use this Access application with no issues at all, but about three of my users are experiencing a peculiar problem.
There is a subform within a form and its contents get loaded through a query. There is a box for a picture, a text box, a check box, and a button on this subform. For myself and 99% of the people using the application, the picture loads and everything appears as it should. For the 3 people experiencing the problem, however, the entire subform is completely blank.
The data is stored in OLE Objects and everybody is using the same data.
I can't figure out why it would work for so many people but fail for others. Does anybody have any ideas?

Related

Microsoft Access Subform Definition Changed

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.

Access Subreport Shows In Print Preview But Doesn't Print/Export

I can't figure out what is going on with my report in Access 2010. When I run it, all the queries and recordsources are generated and the report shows up, perfectly full of data and formatted in print preview. If I try and print a hard copy or export to PDF, the subreports don't print. I have done compact and repair, closed and opened, and check everything I know, but it's not working. The only thing that I can think of is that the subreports are based on temp tables I generate and set within VBA after I pull all the parameters I need. But I don't see why this would cause it to preview but not print? Any help would be greatly appreciated!!
Here's the solution I found... when I moved the table creation code to the button that prompted the report rather than having it use the openargs in the open event of the subreport, it worked. Don't know why exactly it liked it one place better than the other, but I'm glad that it works now!
After many hours in research and experimentation the only solution was a third party print function: http://www.lebans.com/reporttopdf.htm. Leben’s function always produces a printable PDF with visible subreports.
No modification of the report’s properties was of any value, though this is suggested by various posts; it failed to work for me. Similarly, compact and repair failed to help, as did the creation of a wholly new MDB file and importing all the forms/tables/queries. I ran the MDB in Access 2003 and in Access 2010 on another machine and had the same failure.
This points of course to the issue being embedded within Access. Research shows this has been an issue plaguing Access for many years; in its inimitable lack of care for users getting work done Microsoft has failed to even comment on this, much less fix it.
I had a similar issue and thought that I should post my fix in case someone else runs into the same problem.
I had a report with two subreports on it. From a form, I would select from several combo boxes and then hit the button to run the report. When the report opened (in preview and in report-view) it looked fine, and the subreports worked fine. However, when I tried to print or save, the subreports would not show up.
My solution was in my queries and in the form. The report's source queries were pulling criteria from the combo boxes on the form. Once the report was run, the combo boxes would clear, thus clearing the criteria for the queries. After the report is run, the report looks at the queries again when you try to print/save.
If you have a similar setup, I would suggest checking your source queries again after the report is run to see if you are still getting results. You should see the same data in your queries and in your report. If not, there's where to start looking. Hope this helps anyone else struggling with the same issue.

MS Access 2010 Report Design Very slow

I have a MS Access 2010 DB with bunch of forms,queries ,macros, Reports etc
The data for my report comes from ODBC links to SQL Server 2000 Tables via linked table property.
Now, whenever i goto design mode of a report,Everything moves painfully slow (I have to wait atleast half a minute for every mouse click,or to select a text box , or any operation performed on the report)
The report itself takes about a minute to run.Which i dont mind.
All I am looking for, is a quicker way to make changes to the design of reports.
This is an old question, but I had a similar issue with form design running extremely slowly recently. For me, only one form seemed to be affected (all others ran fine in design mode). The record source for the form was a complex query built on a hierarchy of subqueries. I dumped the query results into a table and used the table as the record source for the form instead of the query. This appears to have resolved the issue. Hope this helps someone else.
I found the main cause to be the Access conversion program that converted 2003 format to 2010. If you create a new .accdb and then import all of your object, it should work OK. I definitely fixed my issues
What worked for me is based on the answer provided by Albert Kallal at http://www.utteraccess.com/forum/lofiversion/index.php/t1959800.html.
For me, in my split database, if I open any table that is linked to the backend then opening any frontend form or subform was very quick. If I do not have open and keep open a linked table, then it takes about 20 seconds to switch from Form View to Design View and another 20 seconds to open a subform, etc. When I have a linked table open (it does not matter which table, just any table linked to the backend), then it takes about 1 second to do any of those functions. Huge difference!
That is not normal. Something is wrong. Could be your Office/Access installation, your OS installation, something taking up too much of the system CPU, or your system just not having resources, like memory, to properly run Access. Or that your DB is corrupted and/or bloated.
Two tests you can try.
First, do a compact/repair on the DB and see if that fixes it.
Second, is to start your computer in Safe Mode and see if Access still runs slow. This will test for much of the above issues.
What worked for me was to change the subdatasheet name from 'auto' to 'none' on all local tables. Do this in the property sheet in table design mode. There are routines posted elsewhere that will find all your local tables and change this value.
A table was linked to an Excel file. I found that when the Excel file was open, it took forever to change to design view on ANY form. Closing the Excel file eliminated my problem!
My case is access work fine in every function except opening or designing report. But access can work fine when network disconnect. I found it's cause by printer share by other computer and the computer which was removed. I remove the printer from control panel and access can work smoothly.

Microsoft Access Fixes not Propagating/Errors Not Reproducible In Dev Environment

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.

Access 2007 VBA Listbox lag after changing DB data or Requery

Ive been having an extremely annoying problem that recently started to happen.
My Listbox are not updating right away. For example on my main form "A" has a listbox with an sql statement (Simple... returns 5-20 rows). I have an edit button underneath that when clicked opens a new form to change the data. That form submits an update query and then calls a global function which requiries all of the related listboxes (the one on Form A). The only problem is the listbox doesnt change and seems to hang/lag. if i select the listbox and continuously hit f5, after a few seconds it will randomly refresh correctly.
Does anyone have any idea of what the problem is?
Ive been troubleshooting this for two days now and know its not a network problem as it also happens locally, using a recordset and looping it to manually set the listbox values works fast, but for some reason all my listboxes in my application is doing this.
Is it a setting I accidentally changed or if you define to many relationships does this happen (I recently added another table)?
EDIT:
Forgot to mention, the DB is on a shared drive and is only 2MB, only recently has it started to do this.
I eventually found the problem, hopefully this helps someone in the future.
It had to do with using:
CurrentDB.Execute
this method runs synchronous in the background, therefore the listbox was being refreshed before the sql UPDATE/INSERT/DELETE was complete.
To fix this I instead used:
Docmd.RunSQL
This has solved the problem, however I noticed this method only works on Microsoft Access Databases.