I am using Locate with multiple fields and sometimes I am getting an "Incorrect number of search fields" error and have tracked it down to the data.
tbl.Locate('LName;FName;Stuff',
VarArrayOf([LName+','+FName','+Stuff]),[loCaseInsensitive]);
Sometimes it worked and sometimes it did not and I traced it down to a Comma in the Stuff if it included a Comma in the text.
Stuff = "My dog is gray" would work.
Stuff = "I am at work, but not happy" would not. That extra Comma made it look like four data fields.
Do I have to Parse every string of incoming data for Commas and if any found replace them with what for the Locate to work? The included Comma version will have been stored without Parsing or modifying as I have no idea what they may have entered. "I am at work, but not happy" is a valid input by the user.
Thanks.
Do not concatenate all the search values into a single string. Instead, place them as distinct items in the array, just like the example in the documentation. That is, don't include the commas in the string:
tbl.Locate('LName;FName;Stuff',
VarArrayOf([LName, FName, Stuff]), [loCaseInsensitive]);
Related
I'm receiving the following message:
Table name 'IINR(finishes)' uses special characters that are used in expressions and formulas. Consider renaming the table to remove these special characters.
But I checked and there are no special characters inside any title.
I also tried to create a new app using a different GSheets, in which a copy paste the titles of the columns and in this case, no warning message.
What can it be the reason?
Thanks!
In the end (I didn't read well the message) the problem was on the title of the spreadsheet (table) and not at column level..
Some segments in HL7v2 can be repeating, but what if one of those repetitions is blank? Should the blank repetition be removed? Or should they remain?
For example, in the below extract PID.13 is a repeating field, but the first repetition is blank. It does not even contain "" (empty string).
PID|||A123456789^^^555^PI||Data^Test^^^Mr||19500101|M|||123 Test Road^Testington^^^AA1 2AA||~07778895566|||M|||||||||||||""|||
The PID-13 field has been deprecated as of v2.7 and should no longer be used. Use PID-40 instead.
PID-13 is a special case because the first occurrence has a special meaning, so if there are multiple field repetitions then you shouldn't remove the first one even if it isn't populated. For other fields which don't have documented special cases, you can safely delete empty field occurrence without changing the meaning of the message.
Please refer to this answer.
There are two things needs to be understood.
First:- Empty/blank/null value is also a value. Blank repetitions should not be removed.
Following is what specifications (2.3.2.4 Repetition Separator) say:
2.3.2.4 Repetition Separator.
The repetition separator is used in some data fields to separate multiple occurrences of a field. It is used only where specifically authorized in the descriptions of the relevant data fields. The character that represents the repetition separator is specified for each message as the second character in the Encoding Characters data field of the MSH segment. Absent other considerations it is recommended that all sending applications use '~' as the repetition separator. However, all applications are required to accept whatever character is included in the Message Header and use it to parse the message.
Yes; it does not clearly say anything about removing or keeping empty sub-components. Yes, it neither specifically say that empty value is also a value nor the opposite. I fail to find it in other parts of specifications as well.
To come to the conclusion, we need to move to second thing.
Second:- The sequence of repetition values may also be important. This sequence will change if empty values are removed. This may also change the meaning of the value.
Let us take an example of PID.13 you mentioned in the question.
This field contains the patient's personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the first sequence.
As you can see above, empty value for first sub component tells you that "there is no primary number available for patient". By removing empty value, you are actually putting "secondary number" in place of primary number which may be wrong depending on your use case or implementation.
Other example of PID.3:
This field contains the list of identifiers (one or more) used by the facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.).
As you can see, by removing empty values in-between changes the meaning of identifier.
I will still prefer clear reference from specifications, but based on what said above, I will avoid removing empty values.
I'm trying to query the lucene index I've added to a neo4j field (it's a "name" field, that isn't very long, one to ten words at most).
What I do right now is take all the text in a given webpage, sanitize it with a javascript function to keep only words, spaces and alphanumeric characters, and use that to query my index.
.replace(/[^\w\s]|or|and|not|return+/gi, "") // <- escaping the input
I'm not sure if the length of the search text is limited somehow, but results do seem to disappear after about 1050 words (~6500 characters).
Ideally, I'd like to be able to use a couple thousand words in one query, with the end goal of highlighting the matches found within the webpage itself.
Why is my query not returning any results past a certain number of characters ? Am I missing some keyword in my escaping regex ?
Is what I'm trying to achieve feasible ? Is there a better approach I could use ?
Thanks for reading :)
(for anyone finding this, I found a somewhat related question here: Handling large search queries on relatively small index documents in Lucene)
I am parsing csv file, and I have this row..
45,12,bruine verbinding,mechelse heide,bruin,"276,201,836,338,468",01050000208A7A000001000000010200000002000000443BFF11CF720D41F296072200BD0641189D9C0D026D0D417A50F15264C30641,"MULTILINESTRING((241241.883787597 186272.016616039,241056.256646373 186476.540499333))"
When I convert this string into array by the method
NSArray *arrObjects=[strObjects componentsSeparatedByString:#","];
Then I get 13 objects rather I want 8 objects of array. Objects at index 5 further splits up into five more objects instead of one object(because this object has further commas (,) in string) and index 7 further splits up into 2 objects.
I want only full string object of at index 5 and index 7 instead of five and two objects respectively. I know this is because of method componentsSeparatedByString:#",".
Since the CSV standard allows commas to appear inside a record you can't blindly use componentsSeparatedByString:#"," to separate the fields.
It is actually a rather fussy problem to write a CSV parser that can handle line breaks, commas, and quotation marks as field data.
I would suggest either:
Dictating that the data for a field NOT contain commas, line breaks, or quotes (percent escape each field before saving it to the CSV)
or, if you must deal with data in that format, use an existing CSV library.
A quick Google search on "objective-c csv parser" shows this on Github:
CHCSVParser
Since it claims to be a "proper CSV parser" it should handle fields containing commas.
I am trying to validate uniqueness on an article description. After I save it to the DB, if I retrieve it it comes back in a stripped down format (missing some chars). If I put a validator on the uniquness of the text in the desc. it doens't get called. If I do a find_by_desc it fails since the text is slightly different. Any ideas? I know the table is UTF-8, but really most of the characters are a few line endings and some dashes (-) here or there.
why you don't create an hash-code for that? create it before save, in validation check for the hash comparing. I don't suggest you to compare TEXT fields