Please help with me a conceptual problem I've been trying to figure out for the past 3 days now. I'm trying to use Access to centralize the tracking of training that was previously done on separate excel spreadsheets. I have about ~340 employees that are categorized into 12 different positions all with varying degrees of required training. I have an example below:
Position 1: Class A, Class B, Class C
Position 2: Class A, Class B
Position 3: Class A
Position 4: Class A
As you can see, all 340 personnel require the Class A training. But only some positions require the Class B or even Class C. Right now I have a single table with the individuals name and associated contact information and all 12 possible classes. All I want access to do is store the date they've completed training, nothing else. The problem that I'm running into is that the Date/Time field cannot distinguish between someone that is required to take that class and simply hasn't done it yet (a null value) vs. someone that is not required to take the class and obviously hasn't completed it (also a null value).
What I've tried:
-A query using calculated fields that will enter in the value "NOT REQ" if the job position does not require the training. An example is below:
HAZMAT Inspector: IIf([POSITION]="Load Planner",[HAZ Inspector],"NOT REQ")
Why it doesn't work: Inserting text into the field changes it from a date to a text field so I can no longer use Date functions to determine if training is expired. Also, I cannot edit the field on a form and save it back to the original table due to it being a calculated field.
Possible Solution(?): Use a SQL Update statement in VBA to write the value of a calculated field back into the original table? I still run into the problem that I cannot update the field to begin with on the form...
-Separate Tables for each Position(?): The main problem I see with this is that a lot of positions require the same exact class so I'd be entering in a lot of redundant information.
-Separate Tables for each Class (?): I can see how I'd be safer with this route, but for it to be useful I'd imagine I'd have to write some type of VBA code that says when I assign someone to Position X, his Employee ID is automatically populated in Tables A, B, & C based on his position's training requirements. Is that doable? Is this the best option, or am I just off the mark?
As you already explained, you cannot make entries in a calculated field. You will need a different approach. The approach depends if you display only one employee per form (Single Form) or if you display a list of employees (Continuous Form or Datasheet).
On a Single Form I would simply disable the fields which do not apply
me!txtClassBDate.Enabled = me!txtPosition = 2
You can call this code from Form_Current and possibly in the AfterUpdate of a control used to change the position type.
The other possibility is to use conditional formatting. Select the date-TextBox; then open menu "Format" > "Conditional Formatting..." (I do not know where that is on the ribbons of Acc 2007+). Here you can define the appearance of the control depending on the evaluation of an expression. You can also set the control in a disabled state.
Related
I'm working on an Access 2007 database and I'm having a problem with a query.
I have a table named Vehicles, which contains data such as ID, license plate and fuel type for each vehicle in it.
I'm trying to make a query which will populate a combobox in a Form with each vehicle's fuel type, based on the license plate chosen by the user beforehand.
The thing is, we have some some cars that work with two types of fuel and I cant' find a way to display them separately in the combobox.
So far it kinda works, code follows:
CheckDiesel: IIf([Diesel]="Yes";"Diesel";IIf([Gasoline] AND [Ethanol]="Yes";"Gasoline"+ "Ethanol";IIf([Ethanol]="Yes";"Ethanol";IIf([Gasoline]="Yes";"Gasoline";""))))
If you look at the second IIf, I have a condition for a bi-fuel car. I want to display Gasoline and Ethanol separately, each one in a row.
I've tried using "&Chr(10) Chr(13)&" and "\r\n" but I had no success so far.
Can anyone help me?
Storing multiple pieces of data in a single field rarely ends well. A few options I see
A series of binary fields for gasoline type. So you'd have a True/false for gasoline, ethanol, and diesel. This is easy to show with checkboxes on the form.
If you know there will only be certain combinations, like if there will not be a 'diesel and ethanol' without gasoline, you can build it as a single value combobox.
You will probably need some VBA to do what you need to do. Try something like this:
Dim R as String
R=""
if (Me.Diesel) then R = R & "Diesel;"
if (Me.Gasoline) then R = R & "Gasoline;"
… {add any other types of fuel}
Me.MyComboBox.Rowsource = R
Me.MyComboBox.Requery
This can be added tot he form's OnCurrent event so it will update the combo box every time a new record is displayed.
If your form does not include the various fuel types as fields, either add them as hidden fields or use DLookup to read them off the table.
This is the screenshot of how the final output should look.
However, in the screenshot you will find that purchase total (calculated text label) is the sum total of the first order description Total (calculated at form level): Final Form view section display
The above screenshot result is the output of this formula
=[OrderDescription_tbl].[Form]![Total]
If I use this formula
=Sum([OrderDescription_tbl].[Form]![Total])
The output is #Error.
Troubleshooting I did,
I had created a grand total at the footer of the Subform using
the Sum function and visible parameter set to No and wanted to
reference the output to the Main form Purchase total. How to solve this problem?
However, in the screenshot you will see the number of boxes
count (Not calculated and is a table column), I used the same Sum()
function in the order_description subform. It gives the correct
output. Why is there a difference in output for the same function
one, against the Non-calculated table column and the other, a calculated form text label?
I have used this formula too
=IIf([OrderDescription_tbl].[Form]![Total]>0,Sum([OrderDescription_tbl].[Form]![Total]),0)
Output is still #Error
I have used an query which calculates sum total of each line item and tried to reference this query as
a)=Sum([Query1]![Expr1]) received #Error
b)[Query1]![Expr1] received #Name?
As an alternative to the DSum solution proposed by Kostas, you can use the following workaround:
in the footer of the subform, insert a textBox with the =Sum([Total]) formula, name the textBox BigTotal (or whatever you want)
in the main form, refer to that control: =mySubFormControl.Form!BigTotal
make the subform's footer hidden if you want.
If you have large data sets, this should be faster than the DSum. Also if the subform has an embedded query as its recordSource, you avoid the creation of a queryDef.
Try the DSum() function:
=DSum("[Total]",[OrderDescription_tbl].[Form].[RecordSource])
Thanks! I have been able to solve it using the existing structure only. In this regard I referenced Northwind database.Although,my database would have been more specific and different from Northwind,some aspects from Northwind did give me hints on what to change. The trick was - I had several lookups fixed on numerical columns like unit_rate(and this unit_rate referred a product portfolio table containing product offering of our company).Once, I removed the lookup aspect of these column values, #Error as well as Name? error were automatically resolved. I created a grand total with Visible parameter set to No inside the order description subform and referenced the output of this form to the grand_total text label in the outer form as seen in the screenshots shared.😀 Thank you for the support#Ren Kessler and I will share this is Stackoverflow too so that others can take advice from my case scenario. Ren Kessler I will use your method in some other way,may be in this development scenario but for some other context. I found it quite interesting and I havent tried it. Apart from my reply, I would like to quote you and your solution method too.Total_Calculation_subforminternal_view_Expression_builder_for_grandtotal_textlabel
This is the solution Given by Ren Kessler(Facebook group member):" I solved it in a very convoluted way. I hope someone has a better solution than mine.
I created a series of fields on my form (not fields in a table, but just on the form) that reference the fields on the subform. Then I performed all my math using these form fields. It was the easiest way I could find.
It seems clumsy, but works. As well, it made it easy to use these fields on a report (in my case, an invoice).
In previous versions I did not have to do this. I took a 2002 app where the math worked on the sub form, and used the exact same steps in 2016 and got #error, just like you. This system solved it, but it just doesn't seem right."
I have a field with a customer ID that should be in the format of C0000000001, where it has a letter at the start and up to 10 numbers after the letter with leading zeros between the letter and the number. I want the users to be able to put in C1 and have the table save C0000000001 or C1234 and have the table save C0000001234.
I want the restriction to be on the hard data in the table. The table should contain the full customer ID but I only want the users to have to enter the C and the number of the customer when entering/searching for customers. I am using Access 2010.
I believe that the first character will always be a C, but either way, it would only be one alpha character if it wasn't.
I understand what you are saying, but the majority of the data (thousands of records) are going to be from another system that stores them that way. Doing it this way limits my margin of error. Otherwise, exports from the other system will need to be manually changed prior to being imported into the database and vice versa.
Searching would only be on existing records that will be saved in the C0000001234 format, but I would like user to be able to omit the leading zeros when entering the search criteria.
This question, combined with your previous question here, suggest to me that you are trying very hard to have the data structure in your Access database exactly match the legacy system from which you receive bulk updates. That may not be necessary, or even desirable.
For example, instead of maintaining the CustomerId as Text(11) (as in the old system) you could store it in your Access database as
CustomerIdPrefix: Text(1), and
CustomerIdNumber: Long Integer or perhaps Decimal if the numeric part really can exceed 2,147,483,647
Your Customers table in Access could also include a calculated field named CustomerId as
[CustomerIdPrefix] & Right("0000000000" & [CustomerIdNumber], 10)
to give you a single 'C0000012345' value for display purposes.
For searching, your form could have a Text Box for the Prefix (default value: 'C') and another text box for the numeric part. The search could then use a condition like
[CustomerIdPrefix] = txtPrefix.Value AND [CustomerIdNumber] = txtNumber.Value
or, if the user wanted to create a Filter on the Form (or Datasheet View) it would probably be sufficient to just filter on the number part.
If you ever needed to feed information back to the legacy system you could just export a query that includes the [CustomerId] calculated field (and omits [CustomerIdPrefix] and [CustomerIdNumber]) and you'd be fine.
My suggestion would be to use forms with associated queries using the FORMAT function.
You do need to clarify where you want this implemented, but I'm going to assume you have a table set up and that you would like to be able to enter/search data from a form.
I'll create one form for input frmAdd. For the input form, I created a query that would run when a button on the form was pressed. Add two text boxes newID and newOther to the forms which are unbounded but which the user can use to enter data. The query will then pull that data and append it to your table in an altered format. Here's the SQL for that query:
INSERT INTO Customers ( [Customer ID], [Other Field] )
SELECT Left([Forms]![frmAdd]![newID].[value],1)
& Format(Right([Forms]![frmAdd]![newID].[value],Len([Forms]![frmAdd]![newID].[value])-1),"0000000000")
AS Expr1, Forms![frmAdd]!newOther AS Expr2
FROM Customers;
I'm not sure exactly what search functionality you're looking for, but this query would pull up the record data matching that of a frmSearch with a textbox search which would have the format C### or whatever entered in:
SELECT Left([Customers].[Customer ID],1) & Replace(LTrim(Replace(Right([Customers].[Customer ID],9),'0',' ')),' ','0')
AS Expr1, Customers.[Other Field]
FROM Customers
WHERE (((Customers.[Customer ID])=Left([Forms]![frmSearch]![search].[value],1)
& Format(Right([Forms]![frmSearch]![search].[value],Len([Forms]![frmSearch]![search].[value])-1),"0000000000")));
Applying the input mask is just a way to ensure that your data is correct. If you feel the need to use one, go to the table in Design View and click on the Data Type box for the customer ID field. Find Input Mask under Field Properties -> General and click it. Then hit go to the toolbar -> Design tab -> Builder. This will walk you through it.
Input mask is not the answer for this. Input mask forces the user to input the data in a certain manner. What you need is some VBA code to run in the AfterUpdate event on a form. There's no way within the table to force the data into this pattern allowing the input method that you've requested.
There may be a more efficient way to do this, but this does the job.
http://pineboxsolutions.com/access/customeriddemo.accdb
I have created a small database in Access 2007 that consists of one table and two forms, one for entering data, and one for retrieving data.
My problem is this: On my input form I have a group box with three radio buttons in it. The question being asked is Is the element a sensor?
The buttons represent Yes, No, and Don’t Know.
In the database I have a column named Sensor to hold the value the user chose, but since the radio buttons return a value of 1 for yes, 2 for no, or 3 for don't know, it makes generating a report or query that makes sense to the user very difficult.
At this point I’m writing huge SQL statements with nested iif’s to return the data the way I want to see it.
Is there a way to populate the table with data the way I want to see it (yes, no, don’t know) instead of populating it with 1’s 2’s or 3’s? This is a bound form by the way, I wish I would have done it unbound, but I can’t go back now.
I would suggest not using the radio buttons, and instead opt for a combo box. You'll be able to use string values for the results directly in the combo box.
Now if you are dead set on using radio buttons, try this:
Add a new field to your table that holds text. Bind this to a hidden text box on your form.
Then, add a BeforeUpdate event (or AfterUpdate depending on what you are doing) to the radio group. Add code similar to the following:
Sub RadioGroup_BeforeUpdate(cancel As Integer)
Select Case Me.RadioGroup.Value
case 1
Me.hiddenTextField.value = "Yes"
case 2
Me.hiddenTextField.value = "No"
case else
Me.hiddenTextField.value = "Don't Know"
End Select
End Sub
Now when you save the record, the human readable value will be available in the new field you added.
"since the radio buttons return a value of 1 for yes, 2 for no, or 3 for don't know, it makes generating a report or query that makes sense to the user very difficult."
Store those 3 pairs as rows in a Sensor_Values table:
sval descriptor
1 yes
2 no
3 don't know
Then you can join that table to the table which includes the stored Sensor numbers.
SELECT yt.Sensor, sv.descriptor
FROM
YourTable AS yt
INNER JOIN Sensor_Values AS sv
ON yt.Sensor = sv.sval;
If you're opposed to creating and joining a lookup table, you could use a Switch() expression in your queries to translate the numeric Sensor values to their text forms.
SELECT
Switch(
Sensor = 1, "yes",
Sensor = 2, "no",
Sensor = 3, "don't know"
) AS sensor_text
FROM YourTable;
The Switch() approach can work, but can be more challenging to maintain compared to the lookup table approach.
My intention here was to show you fairly simple methods to use the option group value as a number instead of "populate the table with data the way I want to see it (yes, no, don’t know) instead of populating it with 1’s 2’s or 3’s"
As a general rule, you will be better off working with Access controls as they were designed to be used. Break that rule whenever you have a compelling reason ... but breaking the rule then requires additional efforts from you ... like more VBA code. The approaches I suggested don't require any VBA.
you could use a Select Case when creating the select string, instead of having iif's nested in the SQL.
Select Case Me.rdoSensor
Case 1
sSQL=sSQL & " AND Sensor='Yes'"
Case 2
sSQL=sSQL & " AND Sensor='No'"
Case 3
sSQL=sSQL & " AND Sensor='Don''t know'"
End Select
I'm new to Access so please consider this when forming your response. This has been driving me crazy and I've looked high and low on the 'net for a solution. I look forward to your response.
I have a form with an option group. I've wish to have this display on my report. Take for instance this "test" scenario:
Options
a, b, c
I've created a field in my table to accept the data from the form. In my table, I see 1, 2, 3 when I save a record. Good enough. Now, in my report, I have checkboxes representing options a, b, and c. I wish to have a checkmark within the box corresponding to the option selected on the form.
There's no technical limitation preventing you from displaying output on a report using an Option Group and check boxes.
In the design view of the report, add an option group control from the controls toolbox.
Add 3 checkbox controls to the option group control. When you select the check box control and hover the pointer over the option group, it will change color to indicate that the check box will become a part of the group when placed.
I added three check boxes to an option group on a report and they defaulted to values of 1, 2, and 3, so this should go pretty easily for what you're trying to do.
In the Property Sheet with the option group selected, make sure the Control Source property is set to the column with the 1, 2, 3 value in the underlying data source.
You might want to set the border style to hide the box around the checkboxes and also delete the label control that is automatically generated for the option group. I'm not sure what kind of look you're going for, but I'm sure you can handle the formatting details.
An option group is a user interface object, and UI objects don't belong on reports.
Your data field stores digits, but each of those digits has a meaning. On a report, you want the meaningful data displayed. That means that you need a data table that maps 1, 2 and 3 to something, and then join that table to the field you're storing the option group value in.
Another approach would be to use Switch(), but that means that you'd have to edit the report any time you add another option. A data table makes that a lot easier, as you just add a new record to add a new value.