I was wondering if anyone knew how to create a custom message for the save record confirmation, only using macros and not user coded VBA. I've done this for a previous project in VBA but this time I'm trying to only use Access' macro builder. I'm using Access 2010 to build this project.
So far I've got
IF 6=MsgBox("Are you sure you want to delete this customer's information? WARNING, this is unrecoverable."),52 Then
RunMenuCommand DeleteRecord
MessageBox Message "Customer information deleted."
This makes a yes no dialog box first as the confirmation but it then shows the built-in confirmation that Access bundles with the DeleteRecord command.
Thanks,
Jake.
don't use the run menu command. You could for example delete using SQL
currentdb.execute "DELETE * FROM myTable WHERE myTableId=" & idOfRecordToBeDeleted
Looking for a similar solution myself and after much ado, have a solution. Using Access2013, but should be the same logic.
In my case, I wanted a Yes/No message box to add a record on Yes, and reload the form on No. In your case, leaving out the filters and values, it would be simpler... If yes, RunMenuCommand = Delete Record Else StopMacro. You could set up the specifics for No, but Else handles it for me.
Specifics: I have a form with a combo box (macro is tied to the combo box/After Update property) to select and filter the records. If there is a matching record(s), display it(them). If there is no matching record, display a message (no records) and prompt the user to add one (yes) or not (no).
The entire macro.... (no VB)
ApplyFilter
Filter Name (blank)
Where Condition =="[cID]= "& Str(Nz([Screen].[ActiveControl],0))
Control Name (blank)
If IsNull(eID]) Then
If MsgBox("No record",4,"Nothing found")=6 Then
SetProperty
Control Name cID
Property Value
Value =Str(Nz([Screen].[ActiveControl],0))
StopMacro
Else
RunMenuCommand
Command RemoveAllFilters
StopMacro
End If
End If
Related
I have a MS access data base which has a form from which I want to open a report. There is a choice of 26 reports which all have different name which is a numeric value eg 221.1, 221.2 113.3, etc etc. I have an unbound field in the form which adds the values of four other bound fields and returns a number which should match one of the report names. I have called this unbound field "report Name". I want to add a button that is pressed which opens a report that has the same name as the value in the "report name" field so that if the value is 221.1 it will open report named 221.1 and so on...
I am not used to coding in access and generally rely on the built in commands, macros, wizards etc but in this case I don't think there is a suitable "wizard" to use. Any ideas or help on how I can do this would be gratefully received. I am working in Access 2013 but the data base was written in 2007 and transferred over.
You can get away with just a tiny bit of code in your button's click handler:
Private Sub MyButton_Click()
DoCmd.OpenReport Me![report Name]
End Sub
Add the code just like adding an embedded macro, but by choosing Code Builder instead of Macro Builder. The first and last line should already be there.
I have an Access form with two subforms, both in continuous mode. Since I cannot have a subform inside a continunous form, I had to do it that way (Datasheet is not an option either)
Either way, when I click on my first subform, I change the other subform record source using some rather simple code :
Public Sub MAJFiltre(intIdMembership As Integer)
IdMembershipFiltre = intIdMembership
Me.RecordSource = "SELECT * FROM T_PeriodeMembershipPartipant WHERE IdPeriodeMembreship=" & IdMembershipFiltre
Me.Requery
End Sub
This function is called from the first subform. I did this for another form and it was working fine. For this one, if I use a breakpoint, I can see the recordsource is changed, but nothing happen in the UI. However, if I put a breakpoint in a BeforeInsert event, I can clearly see the recordssource reverting to the original one (with no WHERE clause)
I also notice something unusual : If I save the form code while debugging, all of a sudden, it works. However, as soon as I close the form, it revert back to its "buggy" version.
Does anyway have an idea of what is going on and how I can correct /prevent it ?
Thanks
It sounds similar to a problem we suffer periodically, which relates to subforms linked to a parent form with link master/child ids: If you've (ie Access has done it for you) unintentionally saved a filter value as a property in one of the subforms, (filter by or in a record source), when your code reassigns the record source, this saved value prevents the new record source from being assigned correctly, and ms access then does what it thinks is best - in this case, reverting to the valid (prior) record source.
Check your subforms for unwanted saved values of data-tab properties.
Could the problem be that your field name is misspelled in your query criterion?
IdPeriodeMembreship
If the field in your T_PeriodeMembershipPartipant table is IdPeriodeMembERship instead of IdPeriodeMembREship your query would likely prompt you to enter the parameter value manually when it is run.
If that field does exist in your table but the value you're specifying in your criterion isn't found in that field, it will return no results and the second subform's recordsource will be set to an empty recordset.
I'm new to MS Access, and I have a form with the fields [name] and [company]. I want to make it required for the user to fill out either of those, but not necessarily both. They can fill out [name], [company] or both, but they can't leave both of them blank.
How do I achieve this?
You can do this in vba:
Create an Eventhandler that runs before the saving of a dataset and tell it to cancel the update if your conditions are not met:
Private Sub Form_BeforeUpdate(Cancel As Integer)
If (isnull(me!name) and isnull(me.company) then
msgBox "Give me more !"
Cancel = True
End If
End Sub
I'd recommend Data Macros in this case (if you're using Access 2010 or later). The advantage over VBA is that Data Macro runs at the engine level, so if you have multiple forms with these fields you don't have to duplicate your VBA to every one of them. This also eliminates the problem with starting entering data and then deleting them.
Go to Table design, click Create Data Macros > Before Change and add If condition like this:
You can use VBA to catch the error number 1 to do some stuff. As Access say, the error numbers are user defined and has no meaning to Access.
I am completely new to VBA. I have been told to add records to a table by using a form and a Save button and given some very basic instructions. While I have achieved this with inline query, I have been told to follow some strict methods like usage of QueryDef/QueryDefs and .Parameters.
So far I am trying a very basic project, just to grasp the concepts, but I am unable to add any record to an empty table. In case the table is not empty(I manually enter a record), whenever I click the Save button for saving newer records, the number of records added are somehow doubling with each instance. For example, when I Save for the 1st time, 1 record is added, 2nd time 2 records of the same type is added, 3rd time 4 are added and so on.
The table(tbl_test) has 2 fields --> ID(primary key), Source(Long Text) and Reg No (Number).
The query(qry_test) is made with the Append feature and I have been told to add expressions which makes the code like this -
INSERT INTO tbl_test ( Source, [Reg No] )
SELECT [strSource] AS Expr1, [lngRegNo] AS Expr2
FROM tbl_test;
The form has 2 fields for Source(txt_Source) and Reg No(txt_RegNo) which have blank Record Sources (Unbound). The Save button has the following Event Procedure -
Private Sub btn_save_Click()
Dim qdf As QueryDef
Set qdf = CurrentDb.QueryDefs("qry_test")
qdf.Parameters("strSource") = Me.txt_Source
qdf.Parameters("lngRegNo") = Me.txt_RegNo
qdf.Execute
End Sub
I have zero knowledge about VBA and would gladly accept ANY help. It would be great if I get any sort of source code that will explain to all the details about saving records from forms and editing them using these querydef, parameter and recordset stuff.
Welcome to StackOverflow!
If you are using a form to collect data for records that are stored in a table, running a saved append query by QueryDefs to do this is, in my opinion, not the best method.
Whilst an append query does add new records to an existing table, I would tend to use an append query where I've got multiple established records that I want to add to an existing table.
If I'm setting up a data entry form that is designed to collect new data for new records 1-at-a-time, an append query doesn't really suit this purpose.
Instead, there are a number of features built in to the design of MS-Access forms to help collect data and save it to a table. This is because forms are very much intended to be set up so that users can interact with records from a table in a controlled, user-friendly way rather than interact directly with the table object itself.
The first and most important feature of a form in this context is probably the form's record source property. When you create a new form, go in to design view for the form and open the form's property sheet (F4 key). In the "Data" tab of the form's property sheet you'll find the record source property:
The record source essentially connects your form with a set of records, whether those be records in a table object, a query object or an sql query string.
In your case it would be better, in my opinion, to bind your tbl_Test table to your form by referring to it in your form's record source:
It will seem like nothing has happened to your form, but if you now open the "Add Existing Fields" panel (alt + F8), you'll notice that the fields associated with your tbl_Test table are available to you:
Drag them to the detail section of your form...
Then put your form in to Form View:
Essentially what you and your users are seeing is the first blank record in your tbl_Test, but displayed on a form instead.
Entering data in these fields on the form...
...will put that data in to the table we specified in the form's record source...
So hopefully you can see that setting the form's record source property to that of your table, is much cleaner than trying to get an append query to collect data from your form and deliver it your table.
At this point you're probably asking a few questions:
When I have filled in the fields for a record on my form, how do I save that record?
More can be said about this, but for brevity, I'd recommend using a command button for running some vba to save the record; similar to what you've done, but utilising the form's Dirty property instead using an append query:
Here's the click event VBA for my save button example:
Private Sub cmdSave_Click()
If Me.Dirty Then
Me.Dirty = False
End If
End Sub
Me.Dirty is a Boolean (True or False) setting for the form; essentially it is automatically set to True when a user changes something on the form. To save those changes, the Me.Dirty setting will have to be set to False.
Me.Dirty is a bit like the swing gate on a sheep pen. When a shepherd puts a sheep (data) in the pen (form) they will open the gate to the pen. The open gate is like the form's Me.Dirty being set to True. To lock the sheep (data) in, the gate needs to be closed, or in the case of forms, the Me.Dirty property needs to be set to False. The VBA above essentially checks to see if the gate was opened and if it was to close it.
How do I move to a new record in the form once I have saved the current one?
Again, I'd give the user a command button to do this and run some VBA on its click event:
Here's the VBA for moving to a new record:
Private Sub cmdNew_Click()
DoCmd.GoToRecord , , acNewRec
End Sub
Summary
There is a lot more to consider than what I've outlined here, such as:
validating data before it is saved
checking other form events (such as close) to ensure data entry is not lost
navigating to an existing record
But hopefully what I've given you here is at least pointing you in a better direction. Best of luck!
Access is optimized for bound forms. Unbound forms are for special cases only.
Should you prefer unbound forms (could be for many reasons), Access isn't worth the trouble, and you should turn to Visual Studio and WinForms.
In either case, browse for a beginner's tutorial.
If you want to use an unbound for or unbound controls you can create the SQL string in the procedure:
Dim mysql as String
mysql = "INSERT INTO tbl_test ( [source], [reg_No]) VALUES (Me.txt_Source, Me.txt_RegNo)
DoCmd.RunSQL mysql
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.