How to differenciate (and format) "empty" text fields - postgresql

Recently end users have started to notice explicit simple quotes couples ('') on empty fields.
I have no idea what would have caused that, and was not yet in my company at the time it began to appear.
By looking in the database, I saw a lot of text values filled ''...
...as well as others just kept empty, in the same columns:
I tried to access by query to these values (by trying several syntax)...
...but found no result(with each one of them):
These fields are not null but I cannot seem to access them, and it is quite a big deal if I want to up date them to an empty value (an actual '').
My main goal is to get rid of all the '' appearances to end up having only wether fields filled by users or empty ones. My side goal is to understand better how this happened and how to prevent it in the first place.

In fact they are empty strings and you can find them with this query:
select *
from segments
where se_comments = '';
The second image in the question shows three empty strings, three nulls and two empty strings.

Related

Web2py multi-digit value from dropdown gets treated as a list of values

I have an SQLFORM.factory field:
Field('course', requires=IS_IN_SET(course_query, multiple=True), widget=SQLFORM.widgets.multiple.widget),
that gets its contents from a query:
course_query = external_db.executesql("SELECT course_id, course_title FROM course")
I want the user to be able to select one or more courses, which they can. Upon submit, the course_id(s) they submitted are captured by:
courses = request.vars.course
then I loop through the returned course_id's and insert them into a table:
if form.process().accepted:
for course in courses:
external_db.enrolment.insert(student_id=student, course_id=course)
response.flash = 'Record saved'
This works fine when the user selects more than one course. Each submitted record gets inserted into the database with the correct course_id. But if the user selects only one course, which happens to have a 2-digit ID, only the first digit gets inserted.
I have found that if a single 2-digit course_id value is submitted Web2py treats it as a list, with each digit as an individual element.
How do I make it treat double-digit values from request.vars as a single value instead of a list of values?
Thanks all.
The integer values returned from the browser are actually strings, and when you have just a single value selected, you end up with a single string rather than a list of strings. In Python, when you iterate over a string, you iterate over the individual characters in the string. In this case, a double-digit value is just a two-character string, so your for loop will run once for each digit.
A simple solution is to use form.vars.course instead of request.vars.course. The former will be a list even when only a single value has been selected, so you will be iterating over a list containing a single item rather than iterating over a two-character string.
Note, form.vars will not be populated with the processed form values until after you have called form.process(), so you may need to adjust the order of your code.
As an aside, there is no need to specify the widget argument, as you will get that widget automatically by virtue of using the IS_IN_SET(..., multiple=True) validator.

FullText Index - Searching values from another table

Is it possible, in SQL Server 2008, using the full text index syntax, to run a query such as this one?
SELECT *
FROM TABLE_TO_SEARCH S,
TABLE_WITH_STRINGS_TO_SEARCH SS
WHERE
CONTAINS(S.WHOLE_NAME,SS.FIRST_NAME)
OR CONTAINS(S.WHOLE_NAME,SS.LAST_NAME)
I need to search for the FIRST_NAME in table TABLE_TO_SEARCH, column WHOLE_NAME that has an full text index on it. It doesn't seem to be a valid query though... Is there any workaround to it by using the full text index search?
LATER EDIT:
Here is the business case: each night I am downloading from several websites information about "blacklisted" individuals and insert it into a table in this format: WholeName, LastName, FirstName, MiddleName. But the data is chaotic as WholeName does not necessarily contain either the last, first or middle name or the WholeName is null while the other 3 fields have values, or every of these 4 fields is null and so on. Also, the data may repeat itself as one blacklisted individual may come from 2+ of these websites. What I need to do is to compare this data, as chaotic as it is, against our customer data based on our customer's First and Last name and give it a matching score (rank) against the files we download from these websites.
First I tried with charindex or like operators but I couldn't create a scoring algorithm based on this and also it took 6 hours to compare just our customer's first and last name with only the WholeName column from the TABLE_TO_SEARCH table. I thought that perhaps implementing the full_text index it would get easier and faster but ... apparently I was wrong.
Has anyone dealt with a task like this? And if so, what was the best approach?
After skimming http://technet.microsoft.com/en-us/library/ms187787.aspx and http://technet.microsoft.com/en-us/library/ms142571.aspx I don't think it is possible to do your search in this way. Not only that, but it seems this type of index wouldn't work well with names anyway.
If you care about checking one name then all you have to do is set those values to variables. This method would allow you to use the full-text index.
Otherwise, I would suggest splitting the WHOLE_NAME column (if there is a space or unique character between the first and last name) and comparing each part to those other columns. If you are working with a huge data set, you may want to experiment with doing this at a temp table level and creating an index.
Good luck!

Access Form - Syntax error (missing operator) in query expression

I am receiving a syntax error in a form that I have created over a query. I created the form to restrict access to changing records. While trying to set filters on the form, I receive syntax errors for all attributes I try to filter on. I believe this has something to do with the lack of () around the inner join within the query code, but what is odd to me is that I can filter the query with no problem. Below is the query code:
SELECT CUSTOMER.[Product Number], SALESPERSON.[Salesperson Number],
SALESPERSON.[Salesperson Name], SALESPERSON.[Email Address]
FROM SALESPERSON INNER JOIN CUSTOMER ON
SALESPERSON.[Salesperson Number] = CUSTOMER.[Salesperson Number];
Any ideas why only the form would generate the syntax error, or how to fix this?
I was able to quickly fix it by going into Design View of the Form and putting [] around any field names that had spaces. I am now able to use the built in filters without the annoying popup about syntax problems.
I had this same problem.
As Dedren says, the problem is not the query, but the form object's control source. Put [] around each objects Control Source. eg: Contol Source: [Product number], Control Source: Salesperson.[Salesperson number], etc.
Makita recomends going to the original table that you are referencing in your query and rename the field so that there are no spaces eg: SalesPersonNumber, ProductNumber, etc. This will solve many future problems as well. Best of Luck!
Try making the field names legal by removing spaces. It's a long shot but it has actually helped me before.
No, no, no.
These answers are all wrong. There is a fundamental absence of knowledge in your brain that I'm going to remedy right now.
Your major issue here is your naming scheme. It's verbose, contains undesirable characters, and is horribly inconsistent.
First: A table that is called Salesperson does not need to have each field in the table called Salesperson.Salesperson number, Salesperson.Salesperson email. You're already in the table Salesperson. Everything in this table relates to Salesperson. You don't have to keep saying it.
Instead use ID, Email. Don't use Number because that's probably a reserved word. Do you really endeavour to type [] around every field name for the lifespan of your database?
Primary keys on a table called Student can either be ID or StudentID but be consistent. Foreign keys should only be named by the table it points to followed by ID. For example: Student.ID and Appointment.StudentID. ID is always capitalized. I don't care if your IDE tells you not to because everywhere but your IDE will be ID. Even Access likes ID.
Second: Name all your fields without spaces or special characters and keep them as short as possible and if they conflict with a reserved word, find another word.
Instead of: phone number use PhoneNumber or even better, simply, Phone. If you choose what time user made the withdrawal, you're going to have to type that in every single time.
Third: And this one is the most important one: Always be consistent in whatever naming scheme you choose. You should be able to say, "I need the postal code from that table; its name is going to be PostalCode." You should know that without even having to look it up because you were consistent in your naming convention.
Recap: Terse, not verbose. Keep names short with no spaces, don't repeat the table name, don't use reserved words, and capitalize each word. Above all, be consistent.
I hope you take my advice. This is the right way to do it. My answer is the right one. You should be extremely pedantic with your naming scheme to the point of absolute obsession for the rest of your lives on this planet.
NOTE:You actually have to change the field name in the design view of the table and in the query.
Put [] around any field names that had spaces (as Dreden says) and save your query, close it and reopen it.
Using Access 2016, I still had the error message on new queries after I added [] around any field names... until the Query was saved.
Once the Query is saved (and visible in the Objects' List), closed and reopened, the error message disappears. This seems to be a bug from Access.
I did quickly fix it by going into "Design View" of the main Table of same Form and putting underline (_) between any field names that had spaces. I am now able to use the built in filters without the annoying popup about syntax problems.
Extra ( ) brackets may create problems in else if flow. This also creates Syntax error (missing operator) in query expression.
I had this on a form where the Recordsource is dynamic.
The Sql was fine, answer is to trap the error!
Private Sub Form_Error(DataErr As Integer, Response As Integer)
' Debug.Print DataErr
If DataErr = 3075 Then
Response = acDataErrContinue
End If
End Sub

elasticsearch array field of keywords - how to index it

I've got input that is analogous to tags, where there are a couple of strings per record, and they should be thought of as keywords, not to be tokenized or broken up or analyzed in any particular way. I want it to show up in faceting "as-is", including spaces, slashes, dashes and ampersands.
I don't think I need multi_field here. There is one input value per record "keyPhrases" but the input value is a simple json array of strings.
I want elasticsearch to insert into the facets each of the values, and tag the record with all of the phrases.
Usually there are only one or two or three phrases per record, but there could be more. The set of keyPhrases is fairly small, like 30 or at most like 50. They could be thought of as "categories".
The faceting keeps breaking up the input strings and using lowercasing, even though I'm trying to specify not_analyzed, keyword tokenizer, keyword analyzer, and trying things like that.
I have other fields that keep their spacing and capitalization as I desire in the facets returned, however those fields are not_analyzed and are also store: true, but are also just exactly 1 string input per record, as opposed to many per record.
I could just take the top 1 keyPhrase per record and flatten it, but ideally all the tags would work and be available as facets.
Any ideas on how to do this?
Well, this is embarrassing.
My strict mapping wasn't actually committed to the server at the time I was trying this.
(I was dropping the index and creating the index again with each new mapping, and hadn't realized it, and this was not the final mapping, so it was getting loaded and then dropped.)

Searching Core Data when field contains ' (single quote) character

Please help because I think I'm going mad.
I have a core data collection that contains many thousand records.
Some of the fields in these records contain terms that have a single
quote. When building the database from XML, we created two fields - a
NAME field and a SORTFIELD field.
The NAME field contains the full term and is used for display purposes
in our application.
The SORTFIELD field contains the same content as the NAME field but is
converted to lowercase and has all single quote characters removed
using the following.
[NSString stringByReplacingOccurrencesOfString:#"'" withString:#""];
When the user enters the string for which they wish to search, we
remove single quotes from the search string entered and convert to
lowercase using the same method as when creating the data. However it
does not find any results.
If the user enters Michael's, the system fails to find any records
The predicate is "SORTFIELD like 'michaels'"
If the user enters Michael' (single quote no 's' character), the
system finds all records starting Michael's
The predicate is "SORTFIELD like 'michael'"
I am sure we are doing something very stupid and appreciate any
pointers on how to resolve this issue as we have gone round and round
in circles.
We have placed many NSLog entries to track actual content of the
search fields and record fields and all display as expected.
Thanks
Mike
I finally resolved the issue on finding that the fields being searched
had a non-displayable character when a single quote existed. For
example Michael's displayed but Michaelx's where x= an extended ascii
character, was the actual contents.
By removing this from the fields we were able to perform the searching
as described in our original posting.
However, I still feel that you should be able to search a Core Data collection for strings that contain single quotes without having to do the 'hack' described.
Welcome any thoughts from others on this.
Thanks
Mike