I have 2 reports here that are machine schedules (Wrap & Moulder). They were working great, until I tried to add a checkbox to say whether or not the previous step had been marked completed. It worked initially on Wrap Schedule but when I did the exact same thing on Moulder Schedule it is coming out as data type mismatches. In the checkbox I have put the expression:
=IsDate([Previous_Date_Ran])
It works great on Wrap Schedule, but as soon as a Date is entered in the [Previous_Date_Ran] field I am getting data type mismatches. I have narrowed it down to whenever a date is put into that field, which is odd because when it is Null there is no issue. I have made sure already that my other form that supplies this [Previous_Date_Ran] field is inserting =Date() and not =Now() or =Time(). Below will be screenshots of it working on Wrap but erroring on Moulder.
[
Thank you if you have suffered through with me so far, any help would be much appreciated!
For anyone still struggling here is the steps I took to fix this problem:
Firstly, I have the field Date_Ran as a Date/Time, formatted to short date. Another form has an on-dbl-click event where it inserts today's date in the field. Turns out when you use =Date() in VBA is assigns it a default Variant type. For whatever reason I believe this was what caused the error. The second I switched to using =Date$() it inserts today's date as a string and the error has stopped. Good luck!
Related
Ok this should be a relatively easy thing to do, yet I'm at the head desk stage trying to figure out the insanity here.
I have a table called tblPersonnel. I'm tracking two document expiration dates in date/time fields called CED and PPED. When I run a query against tblPersonnel I need it to look at PPED, determine if that document is expired and if so use CED instead. I have a few fields in the query that need to use this concept to determine what the output value is, but I am hitting a wall here trying to get the query to spit out the correct value. Here's what I'm using for one of the fields - Document Expiration Date: IIf([PPED]-Now()<0,[CED],[PPED]). What's happening is that the expression is constantly popping as false, so PPED is getting used regardless if it's an expired date or not. Does anyone have any ideas as to what I'm doing wrong here?
I've also tried to set this up as its own field in tblPersonnel, but that's even more aggravating. If I try to set the field to just a text field - IIf([PPED]-Now()<0,"Yes","No"), the formula will accept the use of Now(), but it doesn't like the reference to the other fields in the table. If I set it as a calcuated column, I can reference the other fields but it doesn't like Now(). I'm at a loss here.
If PPED is less than Date(), it is expired. Don't need to subtract. Assuming CED and PPED are just date parts, no time, consider:
IIf([PPED] < Date(), [CED], [PPED])
If PPED could be null:
IIf(Nz([PPED],0) < Date(), [CED], [PPED])
Ok finally fixed it here. I had another issue in that I wasn't accounting for how Access would handle a Null or blank value in PPED. The functioning formula is Document Expiration Date: IIf(Len([PPED])>0,IIf([PPED]<Date(),[CED],[PPED]),[CED]) Thanks to June7 for helping me simplify the expression, as I was using DateDiff('d',[PPED],Date())<0 but their answer is just so much cleaner and quicker to type.
This is specifically for MS-Access Web Databases (requires Sharepoint hosting) which has many limitations compared to their client counterparts, like no VBA, instead you get form macros and data macros to manage data.
I've run into a weird bug on one of my applications. I have a query used to check stock levels against a "minimum stock level" also saved in the table. The query is pretty intense and there are over 4,000 records now to check against. These querys normally take about 75s. So I have made a little label that gets updated every time the form is loaded showing the time and date the query was last run, and the duration in seconds it took. (so users can see how fresh the data is and decide if it needs to be run again)
Now, the weird thing is it works fine in my Access client, but when I sync my changes to the server and try it in a web browser I get a "type mismatch" error. A small table is used to store the start and end times whenever the query is run, that's how I get the timestamp data. These fields are in a "Date/Time" format, obviously. But it seems the problem here is changing the date format to a string format so it can be put in a label on the form. The Access client seems perfectly capable of doing this, while the web client stumbles and falls.
My problem is, how do I change data in a date/time format to a string format in a Web database? I can't figure out how to do this. The tools are so limited. I may have to end up answering my own question here but I'm posting this for others just in case.
To return a value from a data macro as string, you have to format the internal date/time format as a string. In Access an internal date/time value is a double number with the integer part as number of days since 1900, and the “decimal” time part is a fraction of 24 hours. Unfortunately if you simply wrap the date/time in the str$() function we had for 20+ years, then you get something JUST like if you type this into the debug window:
? cdbl(now())
41955.5478587963
The solution is to simply pull out each part. And “nice” is while in few cases a data macro will cast the data type, it does in this case and thus the STR$() command is not required.
The expression you thus can use is this:
Month([d]) & "/" & Day([d]) & " Time = " & Hour([d]) & ":" & Minute([d])
So say to pluck out the VERY LAST start time column from say a invoice table, since we don’t have a dmax(), then we simply sort the table in the order we want and pull out the first row.
Our data macro will thus look like:
Note how in above I simply typed in the SQL and SET the order on the date/time column. I want the MOST recent invoice start date and time. For those new to SQL, then I suggest you build a query in the query builder and specify a query in above lookup feature, since many are not "comfortable" typing in free hand SQL as I did above.
Now, in your browser side (UI) macro, you can use this code:
The above returns a formatted string that you can stuff into a text box, or as per above code change the caption of a label.
Unfortunately with silly problems like this, it becomes a path-of-least resistance thing.
Since my intended result was simply to get "a timedatestamp from a table to show up on a form (so users could see when a query was last run)", this became redesigning my form in Access to be a text field instead of a label. Text fields can be adjusted to accept "Time/Date" formats, so this is exactly what I did, it now pulls the timestamp data directly from the last record of the table and requires no extra formatting to appear in the web browser. I redesigned the text field to appear and function more like a label, and my desired function was achieved.
However, since my question specifically asks, "how do you change a time/date format into a string format in a Web db?", I will leave it here in case someone actually does solve it.
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.
I have a strange phenomen I can't explain nor reproduce and I'm hoping you have an idea how it was possible for the user to enter an invalid value.
I have an Access-MDB with a form containing an edit field that should only accept time values without any date-information.
The relevant properties of that edit field are as below:
bound to a Date/Time database value (since access know no time-only datatype)
Format: "Time, 24hrs"
Input Format: "99:99"
(I use the german version of Access, so the property names may be a little different, but you see the pattern)
Now I found out that a user was able to enter a date value into that field. I'm nearly 100% sure that it was an accident and no "clever hack" in the form of directly opening the table and editing the corresponding Date/Time field. Since the entry was made back in 2009 (nobody spotted the error), I have no chance to ask the user how it was done.
I found two wrong entries with the dates "01.06.2000" and "01.07.2000" and I guess the user wanted to enter the times "06:00" and "07:00".
I tried every input I can imagine (like "6.0", "6;0", "6,0", copy&paste) but I was unable to trick access and enter anything except digits and the colon.
Do you have any idea what is going on and how the user was able to enter these dates accidentially?
A Jet/ACE Date/Time value is never stored "without any date information". If you attempt to store only the time component, it will actually be stored with the same time on day zero (Dec 30, 1899).
We can only speculate how the incorrect data was added back in 2009. If you want the database engine to require your Date/Time values to be stored with day zero as the date component, you can add a table-level validation rule. From the table property sheet, try this for Validation Rule:
DateValue([your_date_field])=CDate("1899/12/30")
If you want to allow Null for your_date_field, try this version:
IsNull([your_date_field]) Or DateValue([your_date_field])=CDate("1899/12/30")
Several possibilities:
A developer (you?) did it by accident when looking at the raw table
The client Access software went momentarily crazy and corrupted the entry. This has happen to us (fortunately very rarely) where our Access tables will end up with non-ASCII characters in a string field.
A bug in Access runtime allowed the problem in the past, but has been corrected in a service pack.
Finally, if you put in 90 hours, does it overflow into 4 days and something? That might do it.
I'm trying to display the sum of a field in a text box in the form footer. The field is not calculated in any way.
Here are a couple of the things I've tried:
=Sum([txtWeldInches])
=Sum([WeldInches])
=Sum(CDbl([txtWeldInches]))
=Sum(CDbl([WeldInches]))
...well you get the idea. Each iteration I've used results in the Text Box displaying #Error Without exception.
I've used similar constructs in different forms in the same project, so I'm not sure what the problem might be.
Has anyone run into this before?
EDIT:
I ended up writing a VBA routine to update the boxes when it was likely that they would be changed rather than trying to get a bound sum() function to work.
http://support.microsoft.com/kb/199355
All of the domain functions are based on the same query (over the underlying recordset). If one of the bound functions on the form has a binding error, all of the functions on the form will return an error.
In other words, make sure all your footer controls are resolving properly and not hitting any nulls.
If you use a SUM or AVG then make sure you are also using the Nz function:
ControlSource = =SUM(NZ([FIELD],0))
Is the field "WeldInches" existing in the data source for this form?
What datatype the field "WeldInches" is?
EDIT: I have looked at all your comments. If it doesn't work by databinding, try and use the unbounded way. At runtime, get the value of WeldInches using DSUM and set the footer textbox's value when the form loads.
Also, remember to update it at places where you think the SUM could change.
I had the same problem as Rister.
The source of the form was an underlying query.
I had a bound text box named txtQty on this form. Its control source was Qty (based on the underlying query of the form).
I created an unbound text box and entered =SUM([txtQty]) and received an error.
I tried various ways to find a solution and was very desperate.
Then I deleted the underlying query and created a new one using the same name and fields as before.
Then I entered =SUM([Qty]) into the unbound text box on the form and voila, it worked. Note that I didn't enter the name of the bound text box (txtQty) into the expression, but its control source (Qty). I don't know why, but it worked for me.
I know you said "Form" but for those who have issues with the Sum formula in an Access "Report" the formula has to be in the Report Footer NOT the Page footer. Took me a while to figure it out as Access defaults to only showing the page footer.
You want to sum by the name of the column in the record source: SUM([WeldInches])
Make sure there are no other textboxes with the name WeldInches.