An MS Access form that has been working for over a year now, does a simple:
"Dim MyQuoteID as INTEGER
MyQuoteID = Me.QuoteID"
(It then proceeds to execute an SQL Statement inserting "MyQuoteID" that it just captured from the form)
...Only now it errors and says "Method or data member not found" on "Me.QuoteID".
Of course, the "QuoteID" box is right there, plainly visible, and has been for over a year.
Obviously some kind of corruption because I didn't change anything - but it doesn't solve with a compact and repair!
WTH??????
Two things to try:
Decompile via the command line (msaccess.exe "path\to\your.mdb" /decompile)
Use the undocumented SaveAsText and LoadFromText methods to "export" and "import" your form
SaveAsText acForm, "YourFormName", "YourFormName.txt"
LoadFromText acForm, "YourFormName", "YourFormName.txt"
I think you meant to write TextBox rather than INT. Assuming that this code is in the VBA module for a form, you do not need to define any of the controls in this way, nor is it good practice to do so. Just delete these two lines, and it might fix your problem.
Related
Until now, I manually created a finite number (12) of controls on a report and my code, essentially, turned them on or off (successfully) based on how many the user chose.
Now my client wishes the user to have "no limit" to the number of controls on the report.
My strategy is to delete the controls and create the required number on the fly (via code).
However, when I try to create a control, I get the run-time error 2450 "cannot find the referenced form".
Snippet:
DoCmd.OpenReport "My_report", acViewDesign
Dim ctl As Control
Set ctl = CreateControl(FormName:="My_report", ControlType:=acTextBox, _
Section:=acDetail, left:=2880, top:=0, width:=967, height:=312)
' ... here lies code that adjusts attributes of the controls
DoCmd.OpenReport "My_report", acViewReport
Execution halts on the CreateControl line: ... cannot find the referenced form 'My_report'. (When working, the actual CreateControl code will be in a loop and geometry parameters replaced by variables.)
All discussion I've seen relates to forms but the documentation at CreateControl Method says the first parameter is the "name of the open form or report on which you want to create the control" so it should work for reports too.
Note that the report is open in design mode. Any idea what I'm doing wrong?
Online help / documentation is unfortunately wrong or at least misleading sometimes.
There is a separate method CreateReportControl() for this.
I have a large MS Access 2013 application, and while adding some new logic I've come come upon an obstacle that no amount Googling has allowed me to overcome.
When I run the following code I get a
runtime error 3021: No current record.
error message when executing the last statement:
Docmd.Close acForm,"Picking"
DoCmd.DeleteObject acForm, "Picking"
DoCmd.CopyObject, "Picking", acForm, "Picking On Tablet"
The two forms listed in the code both exist and are proper. The first form (Picking) is being deleted properly in the 2nd statement. (The name has been removed from the list of form objects showing in the nav pane.)
My guess is that I need to somehow refresh the objects list before I run the 3rd statement but can't figure out how to do that. As a lark, I did try DoCmd.RefreshRecord since runtime error 3021 says "no current record" but of course this didn't work.
Am I on the right track? Any other ideas? I'm completely stumped.
You don't mention where your code is located (it can't be in form 'Picking'), but I got the following to work in a Module. You can delete whatever 'RefreshDatabaseWindow' commands you want until you find the culprit...
Option Compare Database
Option Explicit
Sub Do_Something_With_Forms()
RefreshDatabaseWindow
DoCmd.Close acForm, "Picking"
RefreshDatabaseWindow
DoCmd.DeleteObject acForm, "Picking"
RefreshDatabaseWindow
DoCmd.CopyObject , "Picking", acForm, "Picking On Tablet"
RefreshDatabaseWindow
End Sub
Thanks to all for your help. The answers all provided perspective. Based on your feedback I decided to check my work elsewhere. Sure enough, code elsewhere was the source of the issue.
It's times like this when I wish Access would provide stack visibility. What I discovered by hitting F8 some 50-75 times was that I was erroneously executing code to re-establish ODBC links for all my tables, while at the same time essentially, the code in question was manipulating the picking form.
The picking form links to two of the tables and this most likely caused my issue.
After correcting my logic error now the code works fine (yes, it does run in a separate module).
Seems like I've been hitting quite a number of pitfalls after starting out on Microsoft Access. Anyway, the latest one is this: my macro will auto-populate a field in my (datasheet) form whenever the record is dirty, which means that for this field everything is totally behind-the-scenes. Sounds good!
I faced a problem when trying to copy-paste over several columns from Excel though. Access didn't seem to recognise that I was "dirty-ing" more than one row, and consequently help me to auto-populate the fields of all these rows. Instead, it threw me the error message You must enter a value in the "xx.xx" field. followed by a disappointing Do you want to suppress further error messages telling you why records can't be pasted?. It seems Form_Dirty() isn't sufficient for my purposes...
Is there any solution or workaround for this? Let me know your comments and ideas, I'll be more than glad to listen :)
The Dirty event only fires once for the form:
The Dirty event occurs when the contents of a form or the text portion
of a combo box changes. It also occurs when you move from one page to
another page in a tab control.
You can programmatically set the DefaultValue for each form. It needs to be set specifically to a string, though, so requires additional quotes:
Private Sub Form_Open(Cancel As Integer)
Me.txtFirstName.DefaultValue = """Dave"""
End Sub
I would like to know if there is a way to set the parameters in an Access 2007 query using VBA. I am new to using VBA in Access, and I have been tasked with adding a little piece of functionality to an existing app.
The issue I am having is that the same report can be called in two different places in the application. The first being on a command button on a data entry form, the other from a switchboard button. The report itself is based on a parameter query that has requires the user to enter a Supplier ID.
The user would like to not have to enter the Supplier ID on the data entry form (since the form displays the Supplier ID already), but from the switchboard, they would like to be prompted to enter a Supplier ID.
Where I am stuck is how to call the report's query (in the report's open event) and pass the SupplierID from the form as the parameter. I have been trying for a while, and I can't get anything to work correctly. Here is my code so far, but I am obviously stumped.
Private Sub Report_Open(Cancel As Integer)
Dim intSupplierCode As Integer
'Check to see if the data entry form is open
If CurrentProject.AllForms("frmExample").IsLoaded = True Then
'Retrieve the SupplierID from the data entry form
intSupplierCode = Forms![frmExample]![SupplierID]
'Call the parameter query passing the SupplierID????
DoCmd.OpenQuery "qryParams"
Else
'Execute the parameter query as normal
DoCmd.OpenQuery "qryParams"?????
End If
End Sub
I've tried Me.SupplierID = intSupplierCode, and although it compiles, it bombs when I run it. And here is my SQL code for the parameter query:
PARAMETERS [Enter Supplier] Long;
SELECT Suppliers.SupplierID, Suppliers.CompanyName, Suppliers.ContactName, Suppliers.ContactTitle
FROM Suppliers
WHERE (((Suppliers.SupplierID)=[Enter Supplier]));
I know there are ways around this problem (and probably an easy way as well) but like I said, my lack of experience using Access and VBA makes things difficult. If any of you could help, that would be great!
The suggestion being made here is to 100% REMOVE the parameter from the query. This not only solves your problem, but then means you can use the query for code, other forms and not have your whole design fall apart because one stupid form is not open (hence the VERY reason for your question).
So, remove the parameters from the query. This also means that your report will now not need some form that already opened. And again, if some silly form is not opened, why should your report fail to work?
So, remove the parameter. Now, in your form that opens the report, it can pass the filter, and more in point use what is a called a "where" clause. This "where" clause is designed in MS-access to solve the problem of having to know ahead of time what kind of parameters and filters you need. It occurs at runtime, and thus MANY DIFFERENT forms can call and open that report.
Now in the form that calls and opens the form, you go:
Docmd.OpenReport "rptSuppliers",acViewPreview, , _
"SupplierCode = " & me.SupplierCode
So, in the above, the parameter is created on the fly. The great advantage is tomorrow you can have another form open the same report and perhaps filter by region.
In the case of NO where clause being passed and a user simply opening the form, then no filters will be used and no prompts will occur and all records will show. This is probably your best approach.
However if for some strange reason you still deem it REALLY necessary to have some report prompt when one silly form just happens to not be opened, then place the following code in the forms on-open event.
If CurrentProject.AllForms("form1").IsLoaded = False Then
Me.Filter = "SupplierID = " & InputBox("Enter Supplier ID")
Me.FilterOn = True
End
However, I would really make efforts to avoid hard coding some silly form name in the reports open event. Not only does this mean your hard coding dependencies of some silly form that is now attached to a report, but if you later on copy that report, or even copy the original form (or even rename any of these objects), then you have to go into the application and hunt about and now find the places you as a developer introduced dependences. This approach can substantially increase the maintenance costs of an application and thus should be advoied.
So, the suggestion here is to dump the parameter query. Simply provide a form or some prompt system to launch the reports. Those forms should prompt the user for the information you wish to filter. Or as in your case the bound form and it current record provides that information. The beauty of this system is now there is no depdancy from the report.
Any form, or even any code down the road is free to pass a pramaeter, and it will not be limited to SupplierID, but can be any type of filter or parameter you wish.
Keep in mind that perhaps the user might not want that form to be open and perhaps they don't want the prompt. With your design and question the user will be forced to enter a parameter value even when launching the report without any forms open and not desiring to be prompted to allow them to view all reocrds in that report.
As I outlined in a recent post, I tend never to hardwire any parameters or form control references into the recordsources of reports or forms. Instead, I set them at runtime. The simplest way is by passing the WhereCondition property in the DoCmd.OpenForm/DoCmd.OpenReport:
DoCmd.OpenReport "MyReport", , , "[SupplierID]=" & Me!SupplierID
That assumes you're running it from a form that has the relevant SupplierID already present in its recordsource (i.e., you're on a record with that SupplierID).
More complicated is to use the OnOpen event of the report to set the reports's recordsource. That's what I outlined in the cited post above. But that example hardwires the choice to a selection form, whereas you might want to instead offer different sets of choices depending on context. There are two ways to handle that:
if A2003 and later, pass an OpenArg (the last parameter of the DoCmd.OpenReport) to tell the OnOpen event what to do to collect the information on what to filter to.
use an outside structure like a standalone class module to store criteria that the OnOpen event will read and act upon accordingly.
I suspect that the WhereCondition in the DoCmd.OpenReport is your easiest solution, but if you want details on the other two, just ask.
I migrated a database from access 2003 to access 2007.
It seems to work but when I clicked the buttons from A-Z I'm getting this error message:
"Microsoft office can't find the object 'A_Z Schaltfläche'
If 'A_Z Schaltfläche is a new macro or macro group, make sure you have saved it and that you have typed it's name correctly"
I didn't make a new macro but I deleted a word in one of the tables which I think causes the problem: "Like [Formulare]![Frm_Fahrzeugdaten]![Schaltflächenkriterium]"
I found it under the "Record Source" and under one field, that expression is written in the criteria field. If I don't delete this I'm getting a box which says: "Enter Parameter Value" Formulare!Frm_Fahrzeugdaten!Schaltflächenkriterium
My skills in VBA is not really so good, and I need some help how to correct the problem
Thanks for your help.
=======
additional info's:
When I open the VBA code under the Form_Fahrzeugen, here is what I saw:
Private Sub Auswahl_Click()
On Error GoTo Auswahl_Click_Err
' Programmablauf
Me.Filter = "[A_Fahrzeugtyp] like '*'"
Me.Namen_Filter.Value = 27
Me.Schaltflächenkriterium = "*"
Schaltflächenkriterium = "*"
Me.Requery
Me.lfd_Name.Requery
DoCmd.GoToRecord acDataForm, "Frm_Fahrzeugdaten", acGoTo, 1
Me.lfd_Name.Selected(1) = True
Me.A_Inventarnummer.SetFocus
GoTo Auswahl_Click_End
Auswahl_Click_Err:
Call ErrorHandler("Form_Frm_Fahrzeugdaten", "Auswahl_Click", Error$, Err, Erl)
Resume Next
Auswahl_Click_End:
'Ausführungen vor den verlassen der Routine
End Sub
Does it have something to do with the macro name? This is the macro name by the way: "A_Z Schaltfläche"
If I go to the design view of "A_Z Schaltfläche" this is what I got, the conditions are marked yellow I'm not really sure if this is a good sign though:
Thanks
==============
Updates about my problem:
I was able to find the solution of my problem. It was the version of my microsoft office which was causing it. The original database was written in German and when I did the migration, I migrated it to the english version of Access 2007. The reason why it can't find the object because of the name "Ereignisprozedur" in German and "Event procedure" in English. I changed it to Event Procedure because the error says:
"Microsoft Office Access can't find the object "Ereignisprozedur"
If Ereignisprozedur is a new macro or macro group, make sure you have saved it and that you have typed its name correctly
Access was unable to locate the macro or VBA function. If you are trying to call a macro, make sure that the name of the macro and the name of the macro group are spelled correctly.
If you are trying to call a user-defined VBA function, be sure to use the following syntax:
=FunctionName() or =FunctionName(argument1,argument2,...)
Make sure that the function is either:
Defined in the code for the form or report.
- or -
A public function that is in a module (not a class module)."
And the word "Formulare" to Forms. Then the program works.
I can't understand why microsoft programs are language independent???
Do you mean you deleted a word in one of the Queries? What it is is a reference to a form called Frm_Fahrzeugdaten and a control (field, column) called Schaltflächenkriterium. It is under criteria, so the query is saying:
Select such and such where this field (column) is Like this form and this control
It is usual to have
Like "*" & [Formulare]![Frm_Fahrzeugdaten]![Schaltflächenkriterium] & "*"
Or
Like [Formulare]![Frm_Fahrzeugdaten]![Schaltflächenkriterium] & "*"
That is, with wild cards (*)
[Schaltflächenkriterium] seems to me to be the name of an edit control (textbox) in form [Frm_Fahrzeugdaten] for the user to filter a record set.
If you deleted the textbox control, just re-insert it and name it correctly.