The question is simple: Why does this give the wrong answer (0)
IIf(Date()>=#3/16/2018#>=Date()-30,1,0)
While this gives the correct answer (1)
IIf(Date()>=#3/16/2018# AND #3/16/2018#>=Date()-30,1,0)
More specifically, what is Access doing in the first case?
This situation is made even more curious because, when I execute this code, I get an unexpected answer (1)
IIf(Date()<=#3/16/2018#<=Date()-30,1,0)
You can't compound comparisons in Access!
Using your last example, Access first executes the first comparison:
Date()<=#3/16/2018#
That might result in True or False. Let's say it's True
Then, Access evaluates the second comparison:
True <= Date() - 30
(This is since they're processed from left to right, and the first one is true).
This doesn't make much sense, but Access can cast a boolean to a number (-1 = True, 0 = False), and a date too (for example, today = 43186, since dates are defined as the number of days elapsed since 1899-12-30).
That means the second comparison results in:
-1 <= 43186 - 30
And that's certainly true. You also see that if the first comparison is false, the second one will be true nonetheless. Your comparison will pretty much always return true.
Related
I want to cancel the lock when the dates match. I have LockoutEndDateUtc field at database with DateTime.Now.AddMinutes(5)) - value. So tell me the correct syntax for writing this condition please.
if (DateTime.Now == user.LockoutEndDateUtc) { } ?
A few things:
DateTime.Now returns the local time. You should use DateTime.UtcNow instead.
It is nearly impossible to exactly match the current time, because typically these values are tracked with up to 7 decimal places. Instead, you should use >, <, >= or <=.
I'm assuming a few things not stated in your question, but if you meant to lock out the user for 5 minutes, then probably you meant to set the database value with:
user.LockoutEndDateUtc = DateTime.UtcNow.AddMinutes(5);
and probably you should compare it with:
if (DateTime.UtcNow >= user.LockoutEndDateUtc)
Imagine you've got a while loop with an OR condition of two values. The second value has an increment (++). If the first value is true increment from the second value never seems to occur.
Let's take a look at a piece of code:
bool iterationPassed = false;
while (!iterationPassed || ++retries <= 3)
if(somethingHappened)
iterationPassed = true;
Okay, I'm very aware that this is logical. If the first value is true, there's an OR statement, why would there be a need to check the other value. But in this case, the other value is a result of another step (++) and that step never happened. So I guess incrementing or doing any sort of operation in a complex condition is a very bad practice? Also, is this language specific?
I'm trying to write a function of this form:
Function cont(requestdate As Date)
cont = requestdate
End Function
Unfortunately, when I enter =cont(12/12/2012) into a cell, I do not get my date back. I get a very small number, which I think equals 12 divided by 12 divided by 2012. How can I get this to give me back the date? I do not want the user to have to enter =cont("12/12/2012").
I've attempted to google for an answer, unfortunately, I have not found anything helpful. Please let me know if my vocabulary is correct.
Let's say my user pulled a report with 3 columns, a, b and c. a has beginning of quarter balances, b has end of quarter balances and c has a first and last name. I want my user to put in column d: =cont(a1,b1,c1,12/12/2012) and make it create something like:
BOQ IS 1200, EOQ IS 1300, NAME IS EDDARD STARK, DATE IS 12/12/2012
So we could load this into a database. I apologize for the lack of info the first time around. To be honest, this function wouldn't save me a ton of time. I'm just trying to learn VBA, and thought this would be a good exercise... Then I got stuck.
Hard to tell what you are really trying to accomplish.
Function cont(requestdate As String) As String
cont = Format(Replace(requestdate, ".", "/"), "'mm_dd_YYYY")
End Function
This code will take a string that Excel does not recognize as a number e.g. 12.12.12 and formats it (about the only useful thing I can think of for this UDF) and return it as a string (that is not a number or date) to a cell that is formatted as text.
You can get as fancy as you like in processing the string entered and formatting the string returned - just that BOTH can never be a number or a date (or anything else Excel recognizes.)
There is no way to do exactly what you're trying to do. I will try to explain why.
You might think that because your function requires a Date argument, that this somehow forces or should force that 12/12/2012 to be treated as a Date. And it is treated as a Date — but only after it's evaluated (only if the evaluated expression cannot be interpreted as a Date, then you will get an error).
Why does Excel evaluate this before the function receives it?
Without requiring string qualifiers, how could the application possibly know what type of data you intended, or whether you intended for that to be evaluated? It could not possibly know, so there would be chaos.
Perhaps this is best illustrated by example. Using your function:
=Cont(1/1/0000) should raise an error.
Or consider a very simple formula:
=1/2
Should this formula return .5 (double) or January 2 (date) or should it return "1/2" (string literal)? Ultimately, it has to do one of these, and do that one thing consistently, and the one thing that Excel will do in this case is to evaluate the expression.
TL;DR
Your problem is that unqualified expression will be evaluated before being passed, and this is done to avoid confusion or ambiguity (per examples).
Here is my method for allowing quick date entry into a User Defined Function without wrapping the date in quotes:
Function cont(requestdate As Double) As Date
cont = CDate((Mid(Application.Caller.Formula, 7, 10)))
End Function
The UDF call lines up with the OP's initial request:
=cont(12/12/2012)
I believe that this method would adapt just fine for the OP's more complex ask, but suggest moving the date to the beginning of the call:
=cont(12/12/2012,a1,b1,c1)
I fully expect that this method can be optimized for both speed and flexibility. Working on a project now that might require me to further dig into the speed piece, but it suits my needs in the meantime. Will update if anything useful turns up.
Brief Explanation
Application.Caller returns a Range containing the cell that called the UDF. (See Caveat #2)
Mid returns part of a string (the formula from the range that called the UDF in this case) starting at the specified character count (7) of the specified length (10).
CDate may not actually be necessary, but forces the value into date format if possible.
Caveats
This does require use of the full dd/mm/yyyy (1/1/2012 would fail) but pleasantly still works with my preferred yyyy/mm/dd format as well as covering some other delimiters. dd-mm-yyyy or dd+mm+yyyy would work, but dd.mm.yyyy will not because excel does not recognize it as a valid number.
Additional work would be necessary for this to function as part of a multi-cell array formula because Application.Caller returns a range containing all of the associated cells in that case.
There is no error handling, and =cont(123) or =cont(derp) (basically anything not dd/mm/yyy) will naturally fail.
Disclaimers
A quick note to the folks who are questioning the wisdom of a UDF here: I've got a big grid of items and their associated tasks. With no arguments, my UDF calculates due dates based on a number of item and task parameters. When the optional date is included, the UDF returns a delta between the actual date and what was calculated. I use this delta to monitor and calibrate my calculated due dates.
All of this can absolutely be performed without the UDF, but bulk entry would be considerably more challenging to say the least.
Removing the need for quotes sets my data entry up such that loading =cont( into the clipboard allows my left hand to F2/ctrl-v/tab while my right hand furiously enters dates on the numpad without need to frequently (and awkwardly) shift left-hand position for a shift+'.
Today I was working an in-class project with my students when I ran into this bug.
Imgur Link
Pastebin Link
Basically, decTemperature is a String variable that receives an input from the User. In order to teach data validation, short-circuiting, and loops, we were using the following While loop condtionals to force a valid response:
While IsNumeric(decTemperature) = False Or
Convert.ToDecimal(decTemperature) <= 0.0 Or
Convert.ToDecimal(decTemperature) > 135.0
If the user puts in 'abc', in theory the conditional statement should short circuit before reaching the second part of the conditional statement. I attempted the conditional a number of different ways, but ultimately it would crash in every design.
My assumption on the issue probably links closely to an older question I asked about dealing with data types with explicitly setting Option Strict 'on' (although a quick add of Option Strict On in the above code still crashes). That is to say, decTemperature is being processed in each conditional statement before evaluating.
Whatever the case, what is causing the issue and what would be a better approach that still maintains the concepts (that is forcing a valid response from the user)? I have an idea with using a Boolean data type validResponse and setting it, but that seems to be throwing away short-circuiting as a concept.
Or does not short-circuit. Neither does And
OrElse does short-circuit (as well as AndAlso). See OrElse Operator (Visual Basic)
So it should look like this:
While IsNumeric(decTemperature) = False OrElse _
(Convert.ToDecimal(decTemperature) <= 0.0 OrElse _
Convert.ToDecimal(decTemperature) > 135.0)
I would consider using Decimal.TryParse to test the validity of the input.
If you just use Or then every statement is evaluated in every case. That's what the short circuit operators OrElse and AndAlso are for. If you use OrElse the If statement stops the evaluation after the first true statement is detected (or the first false statement in case of an AndAlso).
So in your case the conversion to decimal would be executed in any case. This is avoided with the short circuit operators.
This should be a simple question on JasperReports. I'm trying to do a simple counter over the whole report that should increment based on a condition. However, whatever I try, it seems like the counter variable is always being incremented, regardless of the variable expression. My variable's definition properties are below:
Class: Integer
Calculation: Count
Reset type: Report
Increment type: None
Variable Expression: $F{on_target}.doubleValue() >= 0.0
Initial Value: Integer.valueOf(0)
I have a total of 23 rows in the data set, and based on the criteria, the counter should eventually equal 18. I have the variable outputting in the Summary band, with Evaluation Time to Now. However, regardless of the evaluation time, and even setting the Variable Expression to Boolean.valueOf(true == false), the variable's value always ends up as 23.
What simple little thing am I forgetting?
I think I've got it. This makes vaguely no sense, but... (mind you, this is my first time working with Jasper Variables, so it was trial and error).
The Variable Expression isn't quite a Boolean, where a counter type variable isn't incremented if the expression is false, like you'd think. The variable is incremented if there is any value evaluated in the expression. Thus, for me, what ended up working is below:
$F{on_target} >= 0 ? 1 : null
Note the usage of null if the expression should be false.
It makes vague, twisted sense. But is in no way intuitive. Oh well, so it goes...
or in other words:
When you are using the Calculation:Count function of a Jasper-defined Variable you want the Variable Expression to:
resolve to non-null value to increment the counter
resolve to a null value if you do not want to increment the counter
That's why the test listed above works
As well as the setting the variable expression to:
$F{on_target} >= 0 ? 1 : null
Try also setting the initialValueExpression of the variable to 0.
This worked for me:
$F{on_target} >= 0 ? 1 : BigDecimal.ZERO
No initial variable value necessary.