I have a Microsoft Access 2010 form where the value of a field is determined by a DLookup using a value in a combobox. Here's the control source for the misbehaving text box:
=DLookUp("companyname","dbo_company","companyid = '" & [Companyid] & "'") where [Companyid] is the combobox in the form.
The database itself is stored in MSSQL. When loading a record the text box with the DLookup remains empty until I click on the text box to force it to update. There doesn't appear to be any problem accessing the database, as other fields in the form are being filled fine (including the combobox with the companyid).
Strangely, if I take this Access project and open it on another computer, the text box with the DLookup will load and display the information immediately upon loading a record. This would seem to indicate a configuration issue specific to my computer, but I don't see where such a configuration option would be. Both computers I'm running this on are using Access 2010. There is no code in the "events" handlers, and I'm running the exact same file on both computers (opening over Windows file share). I've already tried doing a "compact and repair", but that didn't change anything.
This also happens when selecting a value in the combobox - the text box will remain empty on one computer, but will update with the DLookup on another computer.
Why would a DLookup run immediately on one computer, but wait until "GotFocus" on another computer?
Well, it looks like this is a bug within Access itself. The issue appears to be some kind of interaction between the Windows Update service and MS Access. When updates get published on patch Tuesday, it causes the Access engine to go wonky. The short-term fix is to restart the computer. You can read more about this in
this lengthy thread on the MSDN forums
The long-term fix is to apply KB2899528 (Access 2010) or KB2956176 (Access 2013). However, note that KB2965300 will overwrite and reintroduce the issue fixed by KB'528 for Access 2010. KB'300 is automatically applied by Windows Update, and now I can't seem to reapply KB'528, so I may be stuck with restarting the server every month.
Related
We have a ACCDB including a lot of forms with expression fields (e.g. "=[FieldA] + [FieldB]"). The ms access db is executed with the access runtime (2019) on a Win10 terminal server. All Forms have been migrated from access 2002 to access 2019 (per OASIS SVN Export/Import).
Mostly the content of expression fields would be displayed as expected, but in individual cases all/some expression fields in the form are empty (also after waiting some time). The content of the other fields is displayed. This beviour is data independend and the field expressions are correct. Mostly ist works, but somtimes not (for the same expression field, data record and form). But if a expression field gets the focus, the content is displayed.
Perhaps it depends on the workload of the pc the access db is running. But i'm not an ms access expert. Another problem is, that an mistakenly empty field could be misinterpred by the user.
One solution is to use the onCurrent event of the form to set the field content explicitly (doesn't work for endless forms) or outsource the calculation in the db view.
I am searching for a general solution, without having to modify all forms (> 150). I can't image this is a general problem with ms access.
Many thanks for any help
Cause of the problem were some java processes started in vba per WScript.Shell and WaitOnReturn option. The problem occurs only if one of the processe was running. As a solution we now avoid the WaitOnReturn option if possible.
I am updating a MS Access away from access. There are some Append Queries that the design view will not come up at all. I read somewhere that if the append is extra old you just need to save the DB as an older version. However, that also fails to do anything.
I am using O365 Access with a 2007-2016 file format DB. It has been upgraded multiple times over the years I would assume it might've started as a 2000 DB.
What can I do to see the design of the append?
If you open the Visual Basic IDE (Alt+F11), and then open the Immediate Window (Ctrl+G), you should then be able to enter the following expression on a new line in the Immediate Window (changing Query1 to the name of your query) and press Enter to view the SQL associated with the query:
?CurrentDb.QueryDefs("Query1").SQL
You could then inspect the tables/queries referenced in the SQL and see if anything is amiss, or copy the SQL to a new query to see if it exhibits the same behaviour.
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.
Right now I'm working on an application in access 2010 that generates letters based of data taken from a share point site. The user inputs some parameters from some combo boxes on a form. After the selection is made the user selects the type of letter they want by pressing a button.
This works fine but I'm experiencing an odd issue when I close access and reopen it later.
When I open the form after starting access again I'll attempt to create a letter but instead of working like it did before the criteria prompt window appears asking for a parameter instead of taking the form values.
This happens every-time I restart access and the way I've been fixing it is by changing the names of the combo-boxes and then adjusting the queries accordingly.
This is what i was using to get the form values in the query
Like [Forms]![Main Menu]![A] & "*" (A is the name of the combo box, I got tired of renaming it)
Any Idea whats going on because I'm at a loss.
Thanks in advance!
If you are 100% positive that Access is finding your parameters just fine, and when Access closes they are lost, then:
Do you have any backup copies of this database before the error
occurred? Can you use one of them?
Do you Compact & Repair the database every time you close it? This
can be used somewhat as "damage control," because MS Access does
have a tendency to become corrupt.
Make sure the Main Menu form is open as long as the query is
running. Does it close right away (aka the query isn't finding the
parameter because the form is closed)?
From searching around, it seems that you aren't the only person with this problem. A known fix for people seems to have been copying all objects into a new database (which to me, sounds like the database is corrupt.) This could also mean maybe only your form is corrupt. Perhaps try to create a new form that does all of the same things that your Main Menu form does.
I'm sorry there doesn't seem to be a 'clear-cut' definitive solution for your situation.
If any VBA is involved, see below:
If you use the "Database Documenter" feature and check "yes" to all the options, you will obtain an exhaustive report that should let you trap your problem parameter. Export this report as an .rtf or .pdf document, so it is searchable. Identify a keyword from the dialog prompt, and search on that.
Once you check the query objects using the Documenter, check your VBA code. You'll do this by stepping through code in the IDE. If the main form has subforms, they are opened with (within) the main form. And they load before the main form.
Identify those subforms.
Sprinkle breakpoints in their code modules (if you find a Load function, that is highly relevant).
If the main form has a code module, do the same there.
From this thread
So I have a shared Access 2007 database that essentially creates this large report, full of nasty subreports and all kinds of other no-no's, and then exports it to a text file which we use for input into a different application. It is a pretty straightforward export of the report to text done using the Access function. No VBA.
Now on my PC, this text file gets exported exactly as it should, while on a co-workers PC, using the same copy of the Access database, the same report, even using it while remote desktop-ing into the same different computer, has different format, spacing, and other goofy Access Report-to-text issues.
My question is: What on earth is causing this given the database is exactly the same and we're getting two different results on two computers? I've tried making sure the default printers are the same, changing around the font in the reports, running it from a Windows server where my co-worker logs into, yet no matter what it seems he always gets the same formatting issues. It seems somewhere, embedded on his and my machine, we have two different controls that are allowing Access to format and export the Report to text different, even though we are using the same database. Any ideas?
Access has a lot of "exciting" options wrt. default printers, make sure you've checked them all.
Open the report in design mode, then go to page setup and see if a specific printer has been selected for that report (Page Setup|Page). If it has, try changing it to use the default printer. If it hasn't, try setting one that you know is on both machines. Either way, save the report.
Make sure you have http://support.microsoft.com/kb/950488 installed, or the specific printer setting won't stick on saving the report in 2007.