if strValue = 'Hello' then what would be the value of (strValue <> 'HELLO') be?
It depends on how you use the Option Compare statement. It can work either way.
Option Compare Text 'Case insensitive'
Option Compare Binary 'Case sensitive (default)'
Here's a VB6 string tutorial.
No, it's case sensitive (by default at least though you'll want to check - if Option Compare is set to Binary or not set then it's case sensitive, if it's set to text then it's case insensitive).
Lcase() both sides if you'd rather it were case insensitive.
The reason I prefer this to changing / setting option compare is that someone looking at the code doesn't have to go hunting to see what option compare is set to to understand how it's going to behave BUT it's almost certainly slower (not significantly unless you're calling it repeatedly) and some might see it as not particularly neat.
The documentation is fairly clear
If you use Option Compare Text in the Declarations section of a
module [the top of the file], string comparisons aren't case-sensitive.
If you use Option Compare Binary, comparisons are case-sensitive.
If you use Option Compare Database [only valid in Access VBA], the comparison method is set by the current database.
Related
I have a dataset with data collected from a form that contains various date and value fields. Not all fields are mandatory so blanks are possible and
in many cases expected, like a DeathDate field for a patient who is still alive.
How do I best represent these blanks in the data?
I represent DeathDate using xsd:dateTime. Blanks or empty spaces are not allowed. All of these are flagged as invalid when validating using Jena RIOT:
foo:DeathDate_1
a foo:Deathdate ;
time:inXSDDatetime " "^^xsd:dateTime .
foo:DeathDate_2
a foo:Deathdate ;
time:inXSDDatetime ""^^xsd:dateTime .
foo:DeathDate_3
a foo:Deathdate ;
time:inXSDDatetime "--"^^xsd:dateTime .
I prefer to not omit the triple because I need to know if it was blank on the source versus a conversion error during construction of my RDF.
What is the best way to code these missing values?
You should represent this by just omitting the triple. That's the meaning of a triple that's "not present": it's information that is (currently) unknown.
Alternatively, you can choose to give it the value "unknown"^^xsd:string when there's no death date. The solution in this case is to not datatype it as an xsd:dateTime, but just as a simple string. It doesn't have to be a string of course, you could use any kind of "special" value for this, e.g. a boolean false - just as long as it's a valid literal value that you can distinguish from actual death dates. This will solve the parsing problem, but IMHO if you do this, you are setting yourself up for headaches in processing the data further down the line (because you will need to ask queries over this data, and they will have to take two different types of values into account, plus the possibility that the field is missing).
I prefer to not omit the triple because I need to know if it was blank
on the source versus a conversion error during construction of my RDF.
This sounds like an XY problem. If there are conversion errors, your application should signal that in another way, e.g. by logging an error. You shouldn't try to solve this by "corrupting" your data.
I am using jQuery to get information from SharePoint 2010's listData.svc. I noticed some inconsistencies with regards to case sensitivity in my queries:
The following command is case sensitive:
...&$filter=substringof('String', property) eq True
The following command is case insensitive
...&$filter=substringof(tolower('String'), tolower(property)) eq True
The following command is also case insensitive but much shorter:
...&$filter=substringof('String', property) or substringof('String', property2)
However, the case insensitivity using the short method is lost for the entire filter when one part is using a property more than two levels down. So in the following command the entire filter becomes case sensitive again:
...&$filter=substringof('String', property/property/property) or substringof('String', property2)
Is this an issue with SharePoint's service? Or am I just doing something wrong?
It seems like a bug in ListData.svc.
If comparisons (delegated to SQL server at the end of the day) are case-sensitive in any query they should always be case-sensitive.
Clearly the tolower call makes things match whether cases match or not, so we can ignore that.
However I have no idea why doing an OR on another property works.
Either it is a bug in SharePoint or perhaps you've inadvertantly picked an OR clause that returns the data your were expecting by accident.
Does any one know how to generate the possible misspelling ?
Example : unemployment
- uemployment
- onemploymnet
-- etc.
If you just want to generate a list of possible misspellings, you might try a tool like this one. Otherwise, in SAS you might be able to use a function like COMPGED to compute a measure of the similarity between the string someone entered, and the one you wanted them to type. If the two are "close enough" by your standard, replace their text with the one you wanted.
Here is an example that computes the Generalized Edit Distance between "unemployment" and a variety of plausible mispellings.
data misspell;
input misspell $16.;
length misspell string $16.;
retain string "unemployment";
GED=compged(misspell, string,'iL');
datalines;
nemployment
uemployment
unmployment
uneployment
unemloyment
unempoyment
unemplyment
unemploment
unemployent
unemploymnt
unemploymet
unemploymen
unemploymenyt
unemploymenty
unemploymenht
unemploymenth
unemploymengt
unemploymentg
unemploymenft
unemploymentf
blahblah
;
proc print data=misspell label;
label GED='Generalized Edit Distance';
var misspell string GED;
run;
Essentially you are trying to develop a list of text strings based on some rule of thumb, such as one letter is missing from the word, that a letter is misplaced into the wrong spot, that one letter was mistyped, etc. The problem is that these rules have to be explicitly defined before you can write the code, in SAS or any other language (this is what Chris was referring to). If your requirement is reduced to this one-wrong-letter scenario then this might be managable; otherwise, the commenters are correct and you can easily create massive lists of incorrect spellings (after all, all combinations except "unemployment" constitute a misspelling of that word).
Having said that, there are many ways in SAS to accomplish this text manipulation (rx functions, some combination of other text-string functions, macros); however, there are probably better ways to accomplish this. I would suggest an external Perl process to generate a text file that can be read into SAS, but other programmers might have better alternatives.
If you are looking for a general spell checker, SAS does have proc spell.
It will take some tweaking to get it working for your situation; it's very old and clunky. It doesn't work well in this case, but you may have better results if you try and use another dictionary? A Google search will show other examples.
filename name temp lrecl=256;
options caps;
data _null_;
file name;
informat name $256.;
input name &;
put name;
cards;
uemployment
onemploymnet
;
proc spell in=name
dictionary=SASHELP.BASE.NAMES
suggest;
run;
options nocaps;
Is there any functionality in IDL that will allow it to evaluate a a string as code?
Or, failing that, is there a nice, dynamic way of including /KEYWORD in functions? For example, if I wanted to ask them for what type of map projection the user wants, is there a way to do it nicely, without large if/case statements for the /Projection_Type keyword it needs?
With even a small number of user options, the combinations would cause if/case statements to get out of hand very quickly to handle all the possible options.
The best bet is to use a case statement because you can't trust that your user is going to type in the same string for Projection_Type that you're expecting as in the keyword.
Though if you are set on doing something like this, there is the EXECUTE function that treats a string as an IDL statement:
Result = EXECUTE(String [, QuietCompile] [, QuietExecution])
Edited to add, there's also CALL_FUNCTION and CALL_PROCEDURE that are faster but maybe less flexible. Look them all up in the IDL help and see what works for you.
What, if anything, is the benefit of using
If StrComp(strVal1, strVal2, vbTextCompare) = 0 Then
as opposed to using
If strVal1 = strVal2 Then
If Option Compare Text is set at the module level, is there any difference?
I know StrComp handles null scenarios and <> scenarios, I am only interested in the situation where strVal1 and strVal2 have non-null valid strings assigned.
If Option Compare Text is set at the module level, is there any difference?
No. It simply offers a finer grained control (no module-level strategy commitments). However, if you can make such a commitment, go for the x = y option: less code is always better code.
Since StrComp is comparing string (with cultural info), UpperCase and LowerCase are not taking care ... (so Hello is the same as hello). In the case of =, there will be different (Like using a Binary compare).
If option compare text is at module level, there will be no difference (but you should use StrComp in case another guy delete it)...