In a grid I have a date/time field where I would like the user to be able to type in short-hand formats for dates and times. For example, if they type in "435p" and then focus off of the cell they get the message "The value you entered isn't valid for this field.". Instead, I want to trap a pre-validationevent and change it to "4:35pm" for them.
What event can I use?
I've tried:
LostFocus & BeforeUpdate: too late (validation fires before event)
Dirty & OnChange: too early (they haven't left the cell yet)
Or is there a way to turn off the native validation rule that is checking for date formats?
You could use an additional text field without formatting (or with your very own format). Then show this instead of the datetime-field and update the date-time field with your code.
Not very pretty, but if you always format the input to a proper time string on before-update and never access this field (but rather the real date-time field) you should be ok. You could even name the field Helper_DateTime or somesuch, so you are never tempted to access the field from anywhere else ;)
Related
I have an Access data table with the Field "RequiredUntil", which is from the type "Date/Time", and several other columns, and a form, in which I show that table, and where I usually use right mouse click to filter for what I want. The text box for "RequiredUntil" is formatted as "Short Date".
Part of the form:
When I now do a right click on the field "RequiredUntil" in that form, Access properly recognizes that as a date, and offers me several date filters, i.e. Today, "This week", Past,... So I don't use any SQL there, all is done by Access!
When I select "Today" (or Yesterday or Tomorrow), I get a "Data type mismatch in criteria expression" error.
When I select "This week" (or any other time period), the filter is properly set - but as soon as I filter the next column, I get a
Syntax Error in Query expression '((Year([DataTable].[RequiredUntil])=Year(Date())) AND
(DatePart("ww";[DataTable].[RequiredUntil];0)=DatePart("ww",Date(),0))'.
In that case, the date filter is revoked, and only the second filter is applied.
So, I don't do any SQL, RequiredUntil is of the type Date/Time, the text field in the Form is Date/Time, Access recognizes it as Date - what am I missing?
I'm pretty sure, the issue is caused by Null values in your date field.
If removed, you can set the filter, which will reveal as:
(DateSerial(Year([DataTable].[RequiredUntil]), Month([DataTable].[RequiredUntil]), Day([DataTable].[RequiredUntil])) = Date()+1)
which, obviously, will fail, as DateSerial doesn't accept Null values.
I have a report which requires user to type the start date and also allow them to choose from calendar. I was wondering if its possible to enter the date as a string. Right now, I have a text field with calendar and I would like the user to enter date[06302015] instead of [06/30/2015]
can we omit the dashes and still have the report format it to date?
The type of a parameter can be changed from Parameter Properties like below.
This will remove the Calendar and it will be only a Text box.
Change your parameter type to "Text".
Add a second "Hidden" parameter (as Date/Time data Type) that takes the LAST_DATE_EDITED as an input into the 2nd parameter's default value using the expression: =DateValue(Mid(Parameters!LAST_DATE_EDITED.Value,1,2) & "/" & Mid(Parameters!LAST_DATE_EDITED.Value,3,2) & "/" & Mid(Parameters!LAST_DATE_EDITED.Value,5,4))
(Not tested, but it should be close)
Then use the 2nd parameter in your report instead of LAST_DATE_EDITED.
If the user inputs an incorrectly formatted string of numbers, uses text, etc., SSRS will throw an exception.
IMO, this isn't the most elegant solution and it demands user input that is prone to errors. Not what I would implement (I would have the users use the built in DateTime picker and train them to use valid separators such as periods, slashes or dashes or just use the calendar control).
I have an ID field with an AutoNumber Data Type that has a custom format defined in the Field Properties (A-00001, A-00002, etc).
I wanted to look up the formatted value and display it in a form textbox control.
ServiceNumber_entry = DLookup("ServiceID", "ServiceRecord", "SNID = '" & Forms!ServiceEntry!PartSN_entry & "'")
Using the line above, it returns just the number value and not the full formatted value (i.e. 1 instead of A-00001). What am I missing?
Existing comments all contain good information, but it can be useful to put it all together. The comments also failed to describe the context in which Access automatically copies and applies properties like Format, so that the comments (even if correct) might seem contradictory. My explanation is a bit verbose, but hopefully avoids further confusion.
The purpose of the Format property for any value in Access is to define how the data is displayed. This is true of a table column presented in a datasheet or a textbox control on a form. The Format does not define how values are stored, either in storage or in memory. The same value could be formatted and displayed differently without affecting the underlying stored datum. In this case, the Autonumber values are really Long Integer values. (They are not stored with a preceding "A-", which would require the values to be strings and would ruin Access's ability to automatically increment the values.)
Access attempts to provide a consistent view of the data and reduce tedious programming details by automatically copying the Format property to queries and form controls, just as it does with many other metadata properties. For instance, if you drag the AutoNumber field onto a form in design mode, it will automatically copy the Format string from the column to the TextBox control's Format property. In contrast, if you include the same column in a query, the query's column property sheet also has a Format property, but it will remain blank by default. However, when the query is executed, it will indeed be displayed with the format defined on the table column. This behavior does not mean that the data values themselves "have a format", rather Access is just doing its automatic work of looking up default formatting values from the table definition and applying it to the query's output. (It can do this if there is a simple one-to-one table column to query column relation, which is the usual case for queries.)
DLookup() is a Visual Basic (VBA) function. It is necessary that such functions handle the "raw" data independently of metadata, like Format (or Caption, Text Alignment, etc.). For coding purposes, a programmer expects to retrieve the actual long integer value from the column, not a formatted string value like "A-00001". The function will not only skip the format, the formatting information is completely dropped from data values. In a programming environment, data can be combined and manipulated and the concept of "format" becomes lost and/or meaningless. Even though in this case it might seem obvious, DLookup makes no assumptions about what you're going to do with the data and so just returns the integer values.
If your form TextBox control was not originally placed on the form specifically for the AutoNumber field, Access would not know to the copy the Format property. It would just display the integers from DLookup() as basic integers. However, you can manually set the TextBox's Format property to match the table column's Format property exactly to get back the expected values.
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 am in the habit of typing date/times in a YYYYMMDDHHmmss format without separators, e.g. "20110807050000" and I want to rig my "date" TextBoxes in an Access form to allow me to enter dates this way.
The TextBoxes in question are databound to Table fields that are of Date/Time type.
The way I have chosen to approach this is just to parse what I type and if I can get a valid date-time out of it, stick it back in the text box. The parsing etc. is complete and ready to go but I am stuck figuring out how to wire it into the form.
Normally (I think .. access/VBA is a bit rusty ..) I would use "BeforeUpdate" event of a control to handle this kind of thing but the problem here is the Form is triggering its default validation error 2113 "the value you entered isn't valid for this field" before it even gets around to running the Control-level events.
Then when I tried parsing/updating the TextBox in the Form_Error procedure, i get a 2115 error "The macro or function set to the BeforeUpdate or ValidationRule property of this field is preventing [...] saving the data in the field." In the Control.BeforeUpdate scenario, I think you can use the "Cancel" flag to get around this sort of hang-up, but Form.OnError event doesn't have anything like that (at least "Response" doesn't seem to be doing the trick.)
edit-just to be complete: I also occasionally might want to use traditional "MM/DD/YY HH:mm:ss [AM/PM]" (or similar) form, and also that I already have parsing in place for pasting dates off the clipboard in another "common" format (the one used in Windows Explorer's Properties dialog), and would like this capability to remain, and remain extendable.
Kinda stumped. Figured I would ask around a bit before resorting to some really invasive/ugly hack to get this working.
Thanks for reading! Any suggestions/solutions are appreciated!
Solution to-date:
Created an additional unbound TextBox to do my data-entry in.
UnboundTextBox.OnLostFocus I try to parse a valid date out of what has been entered and, if a valid date is the outcome, insert that in the original bound TextBox for the field (now Locked).
Form.OnCurrent I copy whatever is in the bound TextBox to the unbound one, to ease editing of existing data.
Pretty basic, and pretty nasty, but, as it's an app for personal use, it's workable, and I've basically already grown accustomed to seeing the extra TextBox on the screen. (I suppose it could be hidden, but I started with it Visible, for debugging purposes, and just left it that way, so far.)
Instead of BeforeUpdate you can use the KeyDown event and have it respond to Enter, Tab, PgUp, and PgDn. This will execute code when you leave the field or record but before validation (what BeforeUpdate SHOULD do). The only drawback is that the code won't run if you use the mouse to leave the field.
I used this to to convert directions like N, NE, WSW to degrees in an integer field. It isn't perfect but is good enough.