I administer a simple Filemaker Pro 12 database for a company. The current project we are working on requires us to italicize proper names. For example, If the database was movie database I would have the following caption:
Wendy,
Peter Pan
At the moment all captions like these are stored in one field, I would normally have two fields to separate the proper name from the character name, but doing so at this point would be very time consuming. I would like to make a script the italicizes the property names in this field, by looping through an array of proper names, and when a match is found it italicizes that name. This would be extremely useful, normally I could do this easily with another language, but Filemakers scripting language is foreign to me. This is simple in other languages using a foreach loop with a string array. Is there a simple solution someone can point me in the direction of.
You could probably loop through the list of proper names (where is it, and in what form?) and set the field to a calculation using:
Substitute ( field ; searchString ; TextStyleAdd ( searchString ; italic ) )
where searchString is the current value of the inner loop. The outer loop is, of course, looping through all found records. Hard to be more specific with so few details.
That said, IMHO it would take no more time and effort to fix the real problem here once and for all, i.e. separate the two facts into two individual fields.
Note also that there is an assumption here that the proper names match only themselves; for example, "Peter Pan, Peter Pan" would become "Peter Pan, Peter Pan" using the above method.
Related
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!
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
i have a kinda weird problem with haystack/elasticsearch trying to find tv episodes stored in my database based on a string like this: 's04e07' which means season 4 episode 7 and is a kind of standard format, but the search index has its problems with that.
Trying a few different things it looks like numbers are not indexed in EdgeNgramFields.
In a CharField i can only find exact word matches like '2013' if contained in the titel, but i have no luck finding 's04e07'.
How do i get my results out of the index?
How could i possibly change the hardcoded default mapping in haystack to index my stuff correctly?
I actually wrote about haystack a few days ago, I would suggest reading that one first:
Django Haystack Distinct Value for Field
It's not directly on point, but my advice here is the same. Stop using haystack.
Haystack comes with an outofthebox edgengram and ngram analyzers, which is cool, except these analyzers don't work in nearly all use cases.
They will especially not work in yours because you are mixing numbers and chars.
But my first question is, why can't you index the data like this:
"season":1
"episode":1
And then at search time break down the users search into the above format?
If that isn't possible, you can still PUT a mapping manually without letting haystack do it for you (which I recommend highly anyway because it's mappings are not correct). It's pretty easy to do with elasticutils.
Keep in mind, I don't think edgengram is exactly what you want here in any event. because it only grams from the edge and is most useful for autocompletes, for example if someone is typing s04e and you want to display a list of possible matches.
So, this depends on how users will query the data. Will it always be the above string whole, or parts of the string, or will they sometimes search for e07 and you want to show all seasons with episode 7's?
The last possibility here is to just index it as normal (haystack will choose snowball) and use prefix queries / regex queries to get what you want.
I have a drop down list of subjects. Two particular subjects are Mathematics and Additional Mathematics. When I choose Mathematics from the drop down list, records from Additional Mathematics and Mathematics are both displayed. Worse is that records from Additional Mathematics are shown first. Many colleagues made mistakes because of this.
How do I make the drop down list such that when clicked, the exact terms are used instead?
This is a problem that is not necessarily unique to FileMaker. You are searching for a name that is imprecise because it is a match for multiple names. Rather instead you might want to search for a unique key whose subject name is 'Mathematics' as displayed in your drop down. It is the use of that unique key that allows you to perform a precise search, even when the name of one subject is a partial or complete match for another.
This solution requires you to add a unique serial number which is, in your case, to alter the Subjects table and add a field called 'idnumber' or similar. The field type should be Number, and the options should include Auto-Enter-Serial number-Generate and On creation-increment by 1. The trick here lies in making sure no two subjects have the same 'idnumber' even when you aren't paying attention, so set the next value to something greater than the number of subjects that already exist. Then from another layout assign each existing subject a unique idnumber, noting that if there are a great many subjects you could script that step.
I should mention that many recommend a best practice of never changing a production layout, but rather to duplicate the layout and make the required changes to the duplicate. This minimizes the effects of testing your changes etc.
Finally, change your layout in inspector such that the drop down list shows Use values from field: 'idnumber'. Select Also display values from second field: 'Subject' and Show values only from second field. Now your drop down is the same clean selection as before. The field will not look correct yet because it will show a number. To make it look correct you can insert another field, selecting 'Subject'. Place that field over top of the 'idnumber' and send 'idnumber' to the back. Fill the 'Subject' field with the correct background solid color instead of none, and enjoy your new precision search capability! The entire process is handled server side so it should not matter that client access is IWP.
If you're using the selection to do a find, put an "==" before the text you're searching on. This will tell FileMaker to do an exact field contents search, instead of a "contains" search.
Is it possible to form an Endeca query to retrieve a field that must start with certain letters? Say like get all users who's first letter is A? I checked with Range filters but it is supporting only numerical fields as well as Wild card search. But nothing worked well so far.
Creating a dimension is one way of approaching the problem as Paul Lemke mentioned.Wildcard is not an option since the performance overhead as well as irrelevant records.
But we solved it using couple of other alternatives.
Create a new property for the Object called "StartWith", store the first letter of the Object and make it searchable. We found it easier than creating a Dimension.
There is a problem where letters like 'A' are usually stop words in Endeca. We can do you a couple of work around to solve this.
Get the ASCII value of the first letter and store the numerical value in to that property. One more advantage with this approach is that we can use Range Filters. But you can't search for 'AB' kind of requirements.
Pre-pend some characters like ^^^My name and search for ^^^M. The advantage with this approach is you can search conditions like letters starts with AB.
Endeca at it's current version (6.1) does not have a search filter that works like a "startswith" function in other programming languages.
I do have two options that might possibly get you close:
If you are truly only looking for the first letter you can setup a Dimension value for each letter of the Alphabet (A,B,C...). You can then refine on each letter and see only the values that start with letter A, B, C, etc. The only downside to this is you can only filter based on how many dimension values you setup. So if you added "A", you couldn't filter anything that started with "AB". You could go down the line and add "AB", "BA, "CA", and so on but that would get unwieldy very fast.
If you want something closer to a "startswith" function the only other option is to use a wildcard search. Basically you would do a property search like this: N=0&Ntk=Username&Ntt=ab*
The trick with wildcard searching is it will do that across multiple words in that property. So assuming you had a data set of these values:
Smithers Smith
Larry Smith
Jenna-Smith
Doing a search of sm* would actually return all 3 results because "sm" was in their last name. Even the one with the dash would return as Endeca think's that is a seperate word. (It might be possible to turn that off though, not sure).
So basically it comes down to this: Stick a one word in a property, set that property to allow wildcard search, then do a "blah*" against that property and you should have the results you're looking for.
Have you tried the First relevance rank module which is supposed to rank based on proximity to the beginning of the field?
It sounds similar to what you are looking for and together with a wild card may produce your intended results.