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.
Related
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.
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
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.
This is not about coding question. It's about Software (Database) Design.
Background: My office has a ADP database as front and SQL Server is a backend. There are a dozen of basic standard reports in the ADP file. End users slightly change reports every year such as adding some texts, changing logo, bolds, highlights. I help them back and forth for updating these. After they are ok with the report, I upload to the server so other users can use it. I do this over and over over the time (hundreds times). I think there should be a better way.
Recently, I test a new design by splitting Report and Database. I let user create a words file for the report that they like. I add MailMerge fields in the report after they're done. My users are very good in MS Words. In the database, I add standard MailMerge code. When users pick what template (docx) they want for a report then runs it, it works fine.
Question: Can I use MailMerge and MS Words as Report Generator instead of Access Report? if it's work fine, I will rollout to all the reports. I just want to miss anything before doing so.
Pro(s)
- Users can add any complex format to a report (almost anything you can imagine in MS Words, which you can't do in Access)
- I have less work. No recode, recomplie, or reupload.
Con(s)
- Report Desinger is run faster than MailMerge for a large report.
- Train user how to update MailMerge fields
Yes, you can use Word and MailMerge to create reports. However, keep in mind that you're giving up control, since users could edit the templates in a way that breaks your MailMerge.
I would like to create an Access report in which the record source is created via ADO code and then set as the record source for the report when the report is run. The problem I am running into is how to add fields to the report since the recordset is bound to the report at run-time and not design time. Is there way I can manually add the field and make sure the field name matches what will be provided in the recordset field collection? Thank you.
The standard solution to this problem is to add all your fields in design view, up to the max available, and hide all of them, and show only the ones you need. Michael Kaplan explained that when he designed the Access Replication Conflict Resolver, this is the approach he used, precisely because adding controls at runtime quickly uses the lifetime limit on the number of controls on a form (700+, but I can't recall the exact number).
It's also just a bad idea, as #Jeff O says, to do design changes at runtime. For one, it means you can never distribute an MDE.
Several ways to do it, but all of them have their issues. create-dynamic report using vba
Other questions have found the folley in working in design mode programatically.