I'm trying to write a little form which accepts some user input, and on the basis of some logic displays one of two possible other forms. Everything is working fine if I use simple, unformatted data, but I hit a problem if the data in question has an input mask of a phone number. Presumably there's a trick here to ignore formatting characters or some such?
The actual logic looks for records in a particular table whose values match the data entered. Something like this cut down example:
A form, which is not associated with any specific table, containing one data entry field, called FormFieldY, and a button whose onClick invokes a Macro whose condition looks for matching data in a table.
DCount("*","TableX","[MyColumn] = [FormFieldY] " ) > 0
Now, if I MyColumn in the table has simple text or numeric values this works just fine. However if I apply a Telephone number input mask to that column, I never get a match. I have tried applying an input mask to my form field, or typing literally into the form field a fully formatted number
(1234) 56789012
neither gives a match. However if instead I hack the macro and enter a suitable hard-coded formatted valueL
DCount("*","TableX","[MyColumn] = '(1234) 56789012'" ) > 0
It works just fine.
I think you may have two issues going on. The first is that your format property displays the parentheses when a user types in a phone number, but those parentheses are not included in the value of FormFieldY --- they are display-only.
You can verify the value of FormFieldY by assigning this code to its After Update event:
Private Sub FormFieldY_AfterUpdate()
MsgBox Me.FormFieldY
End Sub
If you want the parentheses stored as part of FormFieldY's value, perhaps you would get more joy by using an input mask rather than a format. With Access 2003, I used this as my text box control's input mask:
!\(999") "000\-0000;0;_
But it's probably easiest to use the Input Mask Wizard (click the button with 3 dots, which is just to the right of the Input Mask line on your control's property sheet). Choose phone number on the first wizard page. On the Wizard page which asks "How do you want to store the data?", select the "With the symbols in the mask" radio button.
Comment from djna: That was the solution, the expression change below seems not to be needed
The other issue is your DCount expression:
DCount("*","TableX","[MyColumn] = [FormFieldY] " ) > 0
I think you should use the value of FormFieldY rather than the name of the control. That may not be clear, so here's what I mean:
DCount("*","TableX","[MyColumn] = '" & Me.FormFieldY & "'" ) > 0
Related
I have an Access form with a textbox bound to a currency field in a table. As expected, anything other than a numerical entry generates an error. Occasionally, users need to enter several amounts and have those added together and the result entered into the currency field.
To accomplish this, I would like users to enter an equal sign followed by a valid arithmetical string which would evaluate to a number exactly as they would in an Excel cell. For example, if a user enters "=5.31+2" I want the field to evaluate to "7.31" and use that as the value passed to the table when the record is updated or saved. The current workaround is to use the Calculator application but that isn't the ideal solution.
I tried the following code and applied it to both the BeforeUpdate and OnLostFocus events of the textbox (named "tbxTotal_Paid") but neither worked. I simply got "The value you entered is not valid for this field" error.
Dim charCt As Integer
Dim evalStr As String
If Left(tbxTotal_Paid, 1) = "=" Then
charCt = Len(tbxTotal_Paid)
evalStr = Right(tbxTotal_Paid, charCt - 1)
Me.tbxTotal_Paid = CCur(evalStr)
End If
Is this simply applying the code to the incorrect event or is this a coding issue? Any assistance is appreciated.
For me your code looks fine but you might put it in the wrong place.
Like you said Acess is giving you this error because the textbox is bound to the currency-field. So it will never accept non-numerical values because the value-checking code fires even before the before_update-event.
I think the best solution would be to hide your bound text box using Me.tbxTotal_Paid.Visible = False and creating a surrogate textbox which is not bound. You put your code in the beforeUpdate-Event or Change-Event of your surrogate. At the end you should check your final result with IsNumeric(). That way your surrogate textbox writes only correct values to your bound hidden textbox and only numbers arrive at your table.
An alternative would be to change the currency column to a string-field but this would not be wise because of potential wrong data in your database.
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 an Access database that uses linked tables residing on a SQL Server. For one of these tables I created a simple form showing several fields of the underlying table.
I want to switch records using a combo box, so I added one using the Combo Box Wizard, where I selected the option "Find a record on my form based on the value I selected in my combo box".
The combo box works, but I noticed that whenever a new value is selected, Access will briefly return to the first record before displaying the selected record. I can verify this by both noticing a screen flicker (e.g., bound fields briefly display data from the first record), as well as profiling the calls to SQL Server, where I can see one query for the first record, and another query for the selected record.
This problem does not occur if I use the next/previous Navigation Buttons at the bottom of the form.
How can I avoid this unnecessary query?
What using the Wizard did was create a Macro behind the Event of your combobox click. It probably looks something like .. , , First, ="[SomeField] = " & Str(Nz(Screen.ActiveControl,0)) .. What you can actually do, instead of using the Macro, is follow something like this
If we look at what that Macro does (or what arguments it accepts), it is a little more clear on why you may be experiencing that behavior.
The first argument is Object Type then Object Name, then Record, then Offset.
Object Type - The type of object that contains the record you want
to make current. Click Table, Query, Form, Server View, Stored
Procedure, or Function in the Object Type box in the Action
Arguments section of the Macro Builder pane. Leave this argument
blank to select the active object. <- Yours would be left blank because you're referring to the combobox on the form
Object Name - The name of the object that contains the record you
want to make the current record. The Object Name box shows all
objects in the current database of the type selected by the Object
Type argument. If you leave the Object Type argument blank, leave
this argument blank also. <- Because the first was left blank
Record - The record to make the current
record. Click Previous, Next, First, Last, Go To, or New in the
Record box. The default is Next. <- This defaulted to First for me and possibly for you too, probably why you were seeing this 'odd' behavior
Offset - An integer or expression that evaluates to an integer. An
expression must be preceded by an equal sign (=). This argument
specifies the record to make the current record. You can use the
Offset argument in two ways: When the Record argument is Next or
Previous, Microsoft Office Access 2007 moves the number of records
forward or backward specified in the Offset argument. When the
Record argument is Go To, Access moves to the record with the number
equal to the Offset argument. The record number is shown in the
record number box at the bottom of the window. Note If you use
the First, Last, or New setting for the Record argument, Access
ignores the Offset argument. If you enter an Offset argument that is
too large, Access displays an error message. You can't enter
negative numbers for the Offset argument.
I wish I could give you more details, but I have not used Access in conjunction with SQL Server, so if that plays into account I would not have any insight.
I'm using Microsoft Access, I've got a form with three sub forms in. I want to use an auto number in the first field. Once I start entering data in the first record I'd like the auto number to set a temporary variable to use in the other sub forms. I want to set the other sub forms using the default value=[TempVars]![AUTONUMBER].
I'm only using the Macro Builder and I have a problem that the next field I want to enter data in is a required field and has a mask on it.
So Far I've tried:
>GoToControl [AUTONUMBER]
>SetTempVars
>Name: AUTONUMBER
>Expression = [AUTONUMBER]
>GoToControl [Field2]
Here my problem is that it won't let me move from field2 without having filled it in. If I take "is required" off, which I don't want to do, it allows me to go back and forth between fields, but then it screws with the masking.
Thanks in advance
I have a report whose record source is a query, say qryRecords. In the report header I want to add a lengthy notes field (longer than 255 characters). I have set up a table to hold these notes (with a field type "memo"), and because that table is separate from the record source for the report, I was going to put the Notes field in the report using VBA code.
In the open event of the report, I have added this code:
Dim rst as Recordset
Dim sql_qry as String
sql_qry = "SELECT notes FROM tblNotes WHERE id = 1;"
Set rst = CurrentDb.OpenRecordset(sql_qry)
rst.MoveFirst
Me.txtNote = rst![notes] 'I get the run-time error on this line
Unfortunately I get a run-time error where noted ("You can't assign a value to this object"). I found a person with a similar issue on a form, and the suggestion was to move the code from the open event to the OnCurrent event, but that event doesn't exist for a report. Any suggestions? Thanks.
--- Original Question ---
I have a form with an unbound text box (txtNotes), and when the user opens the form, the text box is populated with text that is longer than 255 characters (it concatenates various fields from the database). This works with no problem.
There's a button on the form that opens a report, and in the report, I set the Control Source for a text box to Forms![frmMain]![frmSub]![txtNotes], which is the text box mentioned above. That works too, but for some reason the text on the report is truncated at 255 characters. The form's text box is unbound, so there's no underlying table to limit the length. Does anybody know why this would happen or if there's a workaround?
Most likely when the data from the field is being cast as a Text type rather than as a Memo. Really there's no way to explicitly cast a Text as a Memo (you can go the other way around though with CStr). I had problems with truncation on the form as well when experimenting with this scenario.
I'd suggest you are probably generating this field on the form in the wrong way. Dollars to doughnuts you could generate it in a query (used in the form's Control Source), rather than concatenating it together and placing into an unbound field. Likewise, you could then use that same query as the control source for the report that you are opening.
If all of that is truly impossible, I'd point you at dumping the values from the form into a table specifically for the report and then using the table as a control source for the report.
---- Edit ----
I still contend that you can add it to your Report's data source. In my example below, I've tacked on tblNotes to a select on the Bar table.
SELECT bar.f0, bar.f1, bar.f2, bar.f3, tblNotes.notes
FROM bar, tblNotes
WHERE tblNotes.id = 1;
Yes, if there is 300 rows of Bar, you'll get 300 copies of the same Notes field, but that's a minor problem.
Form there, you just make txtNote's data source the tblNotes.Notes column. txtNote can certainly exist in the report/page header, and when MS Access generates it, it will only use one row. I'm not sure if picks the first/last row, or random row - never the less since they are all the same, it doesn't matter.