A client is looking to have a number field in a database that goes from 1 - 10. However, they would also like the option of "more than 10". Are there any best practices for adding this to a number field (integer) or is it even possible?
This feels like an inane and simplistic question and I'm hesitant to ask it but searches have revealed nothing and I feel like I may be missing a simple trick.
No, not with Access (and most other database applications) anyway. Number fields can only contain valid numbers (or nothing, if NULL is permitted), and neither "more than 10" nor "> 10" is a valid number.
Years ago I did a bit of work with FileMaker Pro and I remember it being quite "loose" in what it would allow to be entered into a field of a given "type". The field's "type" seemed to be more of a "suggestion" as to how an entry was to be interpreted. That opened up a certain degree of flexibility (to handle cases such as yours), but it also often left the user vulnerable to whatever assumptions the software made when interpreting a peculiar value.
In any case, "> 10" would have to be handled as a special case, so you'd probably do just as well to make the field a text field and use a combo box to select the values
1
2
3
...
9
10
more than 10 (or "> 10")
If you want to limit the user's selection to a valid value, i.e. a numeric value between 1 and 10 or a value of "more than 10", I would:
Create a lookup table with two fields ID (long), RecValue (text).
The table will have 11 records, where ID will have the values 1 to 11 and RecValue "1","2",..."10","more than 10".
Use a combobox for the data entry:
RowSource=
Bind on the ID field but show only the RecValue field.
Set "Limit to list" property to TRUE.
The user sees text, but behind the scenes you are using a numeric value.
Related
I have a table containing the following: Five Y/N fields and a calculated field [Priority Results] that totals the number of 'Yeses' from those five y/n fields. I'm trying to create another calculated field that will return a value of Low, Medium or High dependent on the number of boxes that have been checked. [Priority Results] currently returns the values 0 through -5. Low = 0 & -1, Medium = -2, High = -3 or lower. I've tried SEVERAL different versions of If/Then, If/Else, Iif statements and always receive a syntax error. I've read a lot of different sites and the following expression seems to be the most commonly used, but I'm still getting the error. Anyone have any ideas? I've even tried this statement on a non-calculated field and can't get it to work.
IIf([Priority results]<="-1","Low",IIf([Priority results]="-2","Medium",IIf([Priority results]>="-3","High")))
Here are the calculated field [Priority results] properties.
Expression:
[Class Non-Attendance]+[Instructor Referral]+[Late Registration]+[Low Starting GPA]+[Talon Log-in]
Result Type: Long Integer
enter image description here
The part of the table this question relates to has the following fields:
Class Non-Attendance: Yes/No
Instructor Referral: Yes/No
Late Registration: Yes/No
Low Starting GPA: Yes/No
Talon Log-In: Yes/No
Priority Results: Calculated field counting the Yes/No fields above
Priority Outcome: Calculated field (that isn't working) prioritizing based on Priority Results
Don't put parameters for number fields in quotes.
Consider:
IIf(Abs([Priority Results])<=1, "Low", IIf(Abs([Priority Results])=2, "Medium", "High"))
In a query or textbox, expression could be:
Switch(Abs([Priority Results])<=1, "Low", Abs([Priority Results])=2, "Medium", True, "High")
Parts of the question still confuse me, which is why this answer will be brief. You have a calculated field PriorityOutcome based on another calculated field PriorityResults and that is the problem. Access doesn't calculate PriorityResults before calculating PriorityOutcome. Instead Access says PriorityResults doesn't exist yet and passes null to PriorityOutcome resulting in either an error or a silent fail.
There are several fixes you can mix and match. You can repeat the calculation for PriorityResults inside PriorityOutcome: wasteful but often the fastest solution. You can also add a code module with public functions to do part or all of the calculations. Then refer to those public functions in your calculated fields Access intellisense can find public functions.
I am working on a report in Access 2013 I need to seperate the first 20 records in a column that contain a value and assign a name to them. Such as at 1-20 I need it to insert Lot 1 at 21-40 need to assign Lot 2 etc... The report needs to be separated by lots of 20. I can also just insert a line when it reaches sets of 20 without a name if that makes it easier. Just need something to show a break at sets of 20.
Example: As you can see the report is separated by welder stencil. When the count in the VT column reaches 20 I need to enter a line or some type of divider to separate data. What our client is asking for is we separate the VT in sets of 20. I don't know whats the easiest way to accomplish this. I have researched it but haven't found anything.
Example Report with Divisions
Update the report's RecordSource query by adding "Lot" values for each row. There are multiple ways of doing this, but the easiest will be if your records already have a sequential, continuous numerical key. If they do not have such a key, you can research generating such sequential numbers for your query, but it is beyond the scope of this question and no details about the actual data schema were supplied in the question.
Let's imagine that you have such a key column [Seq]. You use the modulo (mod) and/or integer division operators (\ - backslash) to determine values that are exactly divisible by 20, e.g. ([Seq] - 1) mod 20 == 0.
Generate a lot value for each row. An example SQL snippet: SELECT ("Lot " & (([Seq] - 1) \ 20)) As LotNumber ...
Utilize Access report sorting and grouping features --grouping on the new Lot field-- to print a line and/or label at the start of each group. You can also have the report start a new page at the beginning or end of such a group.
The details about grouping can be found elsewhere in tutorials and Access documentation and are beyond the scope of this question.
I have a combo box with a RowSource. When it displays, it shows a list of items that come from a query. The query has two columns. When the user chooses something, the first column is stored in the table, but the second column is displayed (works fine).
When you come to the form and view some existing data, it shows the display value from the query (RowSource) like it should. Works nice most of the time.
The challenge is that one of my combo boxes deals with case-sensitive keys. The wrong stuff is getting shown.
Here is some contrived data:
id value
[a1] [Apples]
[A1] [Oranges]
The underling table is like this:
MyTable
id: int
...other fields...
fruit_key: string
When the fruit_key column contains, "a1", I want to see Apples. When it contains "A1", I want to see Oranges.
What's happening is that I am always seeing Apples because it's doing a case-insensitive match.
How do I change this to case-sensitive?
You can't, except with kludgy workarounds. From How To Perform a Case-Sensitive JOIN Through Microsoft Jet:
The Microsoft Jet database engine is inherently case-insensitive.
And there is no way to change that.
In WHERE conditions and JOINs in queries, you can work with binary string compare: StrComp(Field1, Field2, 0) = 0.
But here, with the bound combobox, your best choice would be to convert the fruit_key string into e.g. a hex string (see Hexadecimal Expansion in the article).
In the rowsource of the combobox you could use a computed column, but in the table you want to edit with the combobox, you'd have to actually store the hex string in addition to the fruit_key, because you can't edit a computed column.
I'm not sure if or how the Binary Field method would work in your case.
All in all you'd probably be better off by
"doing it differently" so that you don't need the case-sensitive data, or
not using Jet as backend, but a server database, where you can set a case-sensitive collation.
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
This might seem like a strange one, but can you store a conditional variable inside a text field (or something that can be made to work like one)?
I'm creating a notification system that groups notification by date and type, so if 2 or more of the same type are created in the same day it will group the notifications together and provide a count (e.g. Person1 and 3 others have done something).
The notification messages are stored in a table as a template e.g.
[[value]] has just done something
[[value]] is then replaced with Person1's name (and count OTHERS) by using
REPLACE(t1.message,
'[[value]]',
IF(t1.value_as_user=1,
CONCAT(t1.forename, ' ', t1.surname, IF((count((t1.id + DATE(t1.date)))-1)<>0,
CONCAT(' and ', (count((t1.id + DATE(t1.date)))-1), ' other'),
'')),
t1.value)) as 'message'
The only problem with this is it would mean that grammatically the message would no longer make sense i.e. "Person1 and 2 others has just done something" should now be "Person1 and 2 others have just done something"
Is there a way to select a string within a text field (like I have done with [[value]]) except have it where it would be something like [[has/have]] and depending on the count the correct one could chosen?
Sometimes you can change the sentence to avoid the grammatical variability:
Something has been done by Person1 and 2 others
(If you read The Elements of Style by Strunk & White, you may be conditioned to recoil at the passive voice. The above trick may seem like cheating. But don't let them bully you.)
Otherwise, no, there's no function in MySQL that can analyze a string and find out its grammatical usage in English and automatically conjugate verbs.
You could make [[has/have]] be another meta-field in your string, and then replace it with another expression based on the count.
But frankly, I wouldn't do the string formatting in an SQL expression. Not only for this reason, but because string-manipulation in SQL is clumsy compared to literally any other language (except Java of course).