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
Related
I have recently taken a job that involves using an Access database to find information. The database in question was built by a developer who left before it was completed. He also didn't leave any documentation behind.
The database uses queries, forms, and VBA. Some of the queries are no longer valid since the source data has a different format than what it was when the database was developed. I know SQL and some basic VBA so I'm trying to modify the SQL; however, I cannot view the SQL behind the queries. I can't open it in Design View or SQL View. I can't even right-click on any object. Not only that but when I open an object, I can't right click on the top tab to close it. There's a red x that populates on the top-right that I have to use. I've tried holding shift when opening the DB, but it still happens. I also went to: menu option Tools -> Startup -> to see if 'Allow Default ShortCut Menus' was unchecked; however, it wasn't. I've checked other forums but haven't been able to find a solution. I think it may be in the VBA somewhere but there are tons of modules and each module has a boat-load of sub procedures in it. I have no idea what else it could be. Any and all insight would be greatly appreciated!
#Andre and #Comintern both provided correct answers. The culprit was in the Auto Exec function and it had a loop that went through each CommandBar and set Enabled = False.
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.
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.
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.
Good day...
The root of my issue is that there's no context menu allowing the user to delete a row from a form. The "delete" button on the ribbon is also disabled. In Access 2003, apparently this function was available, but since our recent "upgrade" to 2007 (file is still in MDB format) it's no longer there.
Please keep in mind I'm not an Access dev, nor did I create this app - I inherited support for it. ;) Now for the details, and what I've tried.
The form in question is a subform on a larger form. I've tried turning "AllowDeletes" on on both forms. I've checked the toolbar and ribbon properties on the forms to see if they loaded some custom stuff, but no. I've tried changing the "record locks" to "on edit", no joy. I examined the query to see if it was "too complicated" to permit a delete - as far as I can tell, it's a very simple two (linked) table join. Compared to another form in this app that does permit row deletes, it has a much more complicated (multi-join, built on queries) query.
Is there a resource that would describe the required conditions for allowing deletes?
Thanks in advance...
Open the query that is the basis for the subform. Can you edit a record? If not, the query is probably the problem.
Are you quite sure the change in functionality happened with the 2007 upgrade? Because the next likely cause is a setting, one of many accesses via the form design interface OR in VBA code.