I have a form and to validate it, I am using eval(). Background is, that I have defined rules in an table. These rules contain placeholders. The rule is compiled and then eval() should check wether its true or false.
Part of one rule contains a check on a listbox value. I identified this to be the problem. I could reduce it to the following:
Application.Forms("frmDMAE").lstHistory.Column(6, Application.Forms("frmDMAE").lstHistory.ListCount - 1)
returns ie 2,
eval("Application.Forms(""frmDMAE"").lstHistory.Column(6, Application.Forms(""frmDMAE"").lstHistory.ListCount - 1)")
returns NULL - but I can not figure out why!?
eval("Application.Forms(""frmDMAE"").lstHistory.Column(6, 5)")
returns NULL as well!? Column 6, row 5 definately contains a numeric value.
Also pasting the following into the debug window shows "2" as return value in both cases:
Application.Forms("frmDMAE").lstHistory(6, Application.Forms("frmDMAE").lstHistory.ListCount - 1)
Application.Forms("frmDMAE").lstHistory.Column(6, 5)
Any idea anyone??? I don't have a dime anymore.
[EDIT]
Solution of Andre works. Just change the indexes of the .Column property within Eval(). Use .Column(rowindex, colindex) instead of .Column(colindex, rowindex)!
[/EDIT]
Thank You very much,
Thomas
Wow. What a strange thing.
Apparently you have to switch the parameters (or array indexes) of the .Column property around when using it with Eval().
My listbox has 2 rows and 7 columns, with a number in the 6th column (= column 5).
? Forms!myForm!myList.Column(5,1)
3600
? Eval("Forms!myForm!myList.Column(5,1)")
Null
? Eval("Forms!myForm!myList.Column(1,5)")
3600
I don't really know what to make of this.
Note: I'm using Access 2010.
Im trying to create a new column which contains true or false. Basically column A has a number in it, between 1 and 6, if its higher than 3 I want the new column 'match' to contain true, otherwise it contains false. Using the add column based on column in trying the following GREL
if(value > 5, "True", "False")
That basically results in EVERYTHING being false.
I know my IF statement is correct because the following works
if(value.length() > 1, "Double", "Single")
Im just confused why if Value is greater than 5 doesnt work, its obviously missing something but I cant seem to pinpoint it in the docs.
Your GREL if() is correct. Our docs for that are here:
https://github.com/OpenRefine/OpenRefine/wiki/GREL-Controls
But I wonder if you really have all number values in that Column ?
Are all the values "green" color ?
If not, try using Edit Column to Trim Whitespace and then convert the Text to Numbers.
Then try your if() on that column again and see what happens.
I've looked through a number of tutorials and asks, and haven't found a working solution to my problem.
Suppose my dataset has two columns: sort_order and field_value. sort_order is an integer and field_value is a numerical (10,2).
I want to format some rows as #,#0 and others as #,#0.00.
Normally I would just do
iif( fields!sort_order.value = 1 or fields!sort_order.value = 23 or .....
unfortunately, the list is fairly long.
I'd like to do the equivalent of if fields!sort_order.value in (1,2,21,63,78,...) then...)
As recommended in another post, I tried the following (if sort in list, then just output a 0, else a 1. this is just to test the functionality of the IN operator):
=iif( fields!sort_order.Value IN split("1,2,3,4,5,6,8,10,11,15,16,17,18,19,20,21,26,30,31,33,34,36,37,38,41,42,44,45,46,49,50,52,53,54,57,58,59,62,63,64,67,68,70,71,75,76,77,80,81,82,92,98,99,113,115,116,120,122,123,127,130,134,136,137,143,144,146,147,148,149,154,155,156,157,162,163,164,165,170,171,172,173,183,184,185,186,192,193,194,195,201,202,203,204,210,211,212,213,263",","),0,1)
However, it doesn't look like the SSRS expression editor wants to accept the "IN" operator. Which is strange, because all the examples I've found that solve this problem use the IN operator.
Any advice?
Try using IndexOf function:
=IIF(Array.IndexOf(split("1,2,3,4,...",","),fields!sort_order.Value)>-1,0,1)
Note all values must be inside quotations.
Consider the recommendation of #Jakub, I recommend this solution if
your are feeding your report via SP and you can't touch it.
Let me know if this helps.
Hey, I have a report parameter which looks like this: 01.01.2009 00:00:00
Its a date (as string), as you might have guessed :). The problem is, this param can be an empty string as well. So I tried those expressions:
=IIf(IsDate(Parameters!DateTo.Value), CDate(Parameters!DateTo.Value), "")
=IIf(Len(Parameters!DateTo.Value) > 0, CDate(Parameters!DateTo.Value), "")
Both dont work and the value for the textfield where I print the expressions result is always #Error. As soon as I remove the CDate stuff, it works, but I have to use it. IS there another way to achieve that? What I want is to display nothing if its not a date or the date (format dd.mm.yyyy) if its a date.
Ideas?
Thanks :)
All arguments to the IIf are evaluated, which results in your error, since the CDate will fail for an empty string.
You can get around this by just writting a function along these lines, using a standard if statement:
Function FormatDate(ByVal s As String) As String
If (s <> "") Then
Return CDate(s).ToString()
Else
Return ""
End If
End Function
Then call it with: =Code.FormatDate(Parameters!DateTo.Value)
First, fix your database to properly store dates rather than doing these workarounds. You probably have bad data in there as well (Feb 30 2010 for example or my favorite, ASAP). Truly there is no excuse for not fixing this at the database level where it needs to be fixed except if this is vendor provided software that you can't change (I would yell at them though, well notify them really, and ask them to fix their data model or go to a new product designed by someone who knows what they are doing. A vendor who can't use dates properly is likely to have software that is very poor all around).
In the query that you use to select the infomation, have you considered just converting all non-dates to null?
This struck me as really weird behaviour and I spent a while checking for bugs in my code before I found this
"out copies from the database table or view to a file. If you specify an existing file, the file is overwritten. When extracting data, note that the bcp utility represents an empty string as a null and a null string as an empty string." (from http://msdn.microsoft.com/en-us/library/ms162802.aspx)
Obviously this allowed me to fix my problem but can anybody think of or does anybody know a reason why this is the case?
It's been some time, but I'm sure it's a backwards compatibility/legacy back to SQL Server 6.5
SQL Server 6.5 could not store empty string: there was always one space. This changed with SQL 7
So '' -> NULL and ' ' -> '' is correct from an ancient history perspective.
SELECT ARTICULO as Articulo,
case when rtrim(CCOLOR) = '' then null else rtrim(CCOLOR) end as Color,
case when rtrim(TALLE) = '' then null else rtrim(TALLE) end as Talle,
from precios
Send null in place of empty.
I find the best solution here:
https://bytes.com/topic/sql-server/answers/143738-bcp-inserting-blank-space-empty-string
I found a work around, using a Case structure in the sql query to
change empty string to a null. The BCP in turn outputs the resulting
null as an empty!
Thanks for your assistance.
Eric
This is related to the "default values" section for BCP:
https://learn.microsoft.com/en-us/sql/relational-databases/import-export/keep-nulls-or-use-default-values-during-bulk-import-sql-server
For example, if there is a null field in a data file, the default value for the column is loaded instead.
You have to think back to days where importing plain text files from other weird systems. BCP translates '' as "not defined"(=missing data) and sets a NULL in the database (=missing data). The other way around a NULL from database must be a '' for the other systems.
To get the 'real' data out of the database use the -k switch:
https://learn.microsoft.com/en-us/sql/relational-databases/import-export/keep-nulls-or-use-default-values-during-bulk-import-sql-server#keep_nulls
The following qualifiers specify that an empty field in the data file retains its null value during the bulk-import operation, rather than inheriting a default value (if any) for the table columns.
Then you have your ASCII 0x0 in your file/database.