Ancestry.com

Ancestry Search: Improved Wildcard flexibility

Posted by Anne Gillespie Mitchell on January 4, 2010 in Searching for Records

Improved Wildcard flexibility has been one of the our most requested feature updates. So to start out 2010 on a happy note, we’ve updated our wildcard functionality.

Previously, you had to use three characters and then either a * or a ?. We’ve made a few changes:

  • Now you can put a wildcard first, such as *son or ?atthew to catch all of those crazy spellings and variations that our ancestors came up with.
  • Either the first or last character must be a non-wildcard character. For example, Han* and *son are okay, but not *anso*
  • Names must contain at least three non-wildcard characters. For example, Ha*n is okay, but not Ha*

These changes apply to both simple genealogy search and advanced search, and both old and new search.

Do wildcards work with exact matches?

Wildcards do work with exact matches and they will give you a lot more flexibility in how you retrieve records. Note: they do not work with Soundex matches, just exact or ranked.

Exactly what is a wildcard?

We allow you to use two wildcards in your name searches: the * (asterisk or star) and the ? (question mark).

The * matches zero or more characters. So if you type in Ann*, this will match names such as Ann, Anne, Anna, or Annabelle.

The ? matches one and only one character. So if you type in Ann?, this will match names such as Anne or Anna but not Ann or Annabelle. If you use Ann?* you will match Anne, Anna or Annabelle, because you must match at least one character after the nn.

Some examples

So if you are having a problem finding a Smith, you might try Sm?th, as this will match both Smyth and Smyth or you might try Sm?th? so you can match Smithe, or Smythe.

Or if you searching in one of those sets of historical documents where all the T‘s look like J‘s or S‘s, try using a ? or a * at the beginning of the name.

If you are searching for names such as Sally or any other name such with a double letter, try substituting the second letter with a *. This way if it wasn’t written down that way, you’ll still get a match. Mat*hew matches Mathew and Matthew.

Remember, just because you know how the name is spelled, doesn’t mean that’s how your ancestor wrote it down, or the person who recorded the name wrote it down, or how the person who transcribed the document indexed it. I was looking at a document for my g-g-g-grandfather, Tartlon Gillespie just yesterday, and his last name was spelled Gilaspie, Gillaspie and Gillispie all on the same document. I always search for Gillespie as Gill?spie just to cover the most common three spellings I know of.

If you’ve got other examples of using the * or the ? wildcard successfully, post them here as a comment. You might just help someone find that ancestor that can’t locate.

Happy Searching and Happy New Year!

Anne Mitchell

About Anne Gillespie Mitchell
Anne Gillespie Mitchell is a Senior Product Manager at Ancestry.com. She is an active blogger on Ancestry.com and writes the Ancestry Anne column. She has been chasing her ancestors through Virginia, North Carolina and South Carolina for many years. Anne holds a certificate from Boston University's Online Genealogical Research Program, and is currently on the clock working towards certification from the Board for Certification of Genealogists. You can also find her on Twitter, Facebook and Finding Forgotten Stories.

61 comments

Comments
1 JoJanuary 4, 2010 at 12:40 pm

Yea! & Thank you! Especially for the wildcard at the beginning. :)

2 MicheleJanuary 4, 2010 at 12:53 pm

I’m glad to finally see this improvement. The limitations to the use of wildcard characters at the beginning of the name has been a big frustration. Thanks!

3 LauraJanuary 4, 2010 at 1:03 pm

YAY! I knew about the wildcards before, but this will definitely help with those difficult names in my husband’s family – Thomson vs Thompson, etc. So, if I wanted to check for misspellings of Thomson, I could just do Th*son and it would get both spellings? Will have to try it out tonight. Thank you!

4 JadeJanuary 4, 2010 at 1:03 pm

A great New Year’s present! Thanks, and hope it works!

5 ValerieJanuary 4, 2010 at 1:11 pm

I can’t seem to get this to work. Mostly, I get an error saying “too many matches.” Then, when I do get results, I get an error stating “Due to current technical difficulties, only partial search results are shown above. Please try your search again later to see full results.”

I’m using old search, with exact checked and searching for Leveret *aters or ?aters (soundex) in Georgia with a date range. Leveret isn’t exactly a crazy common name and I’ve narrowed it down quite a lot. Any tips?

6 Anne MitchellJanuary 4, 2010 at 1:59 pm

Re #5, Valerie, good question. Wild cards don’t work with Soundex, just exact and ranked search. I’ve updated the post to reflect that.

7 Jim LivermoreJanuary 4, 2010 at 2:19 pm

“Names must contain at least three non-wildcard characters. For example, Ha*n is okay, but not Ha*”

So close, Anne. Why the above limitation? Why can I use a single letter in an exact search without a problem? Why not H* or Ha*? This is really what I’ve been waiting for.

8 Larry Van WormerJanuary 4, 2010 at 2:35 pm

I’ve been using the improved wild card capability in old search for a while now? First noticed it maybe a month ago, and commented in a blog entry at that time. A very nice improvement in any case! With the change I’ve found a few ancestors I’d missed previously, due to transcription or original spelling oddities.

9 Larry Van WormerJanuary 4, 2010 at 2:43 pm

While I’m very happy with the improvement, a further change that would really help me would be the ability to EXCLUDE specific letters in names. For example, if I could specify that any surname containing the letter B was not to be included in the results, that would significantly improve the search for me. (Most definitely NOT a complaint, I’m quite happy with what we now have, but a suggestion…)

10 Anne MitchellJanuary 4, 2010 at 3:06 pm

Jim, the three letter limit is because we don’t want to overwhelm the system. When you have billions of records, a single letter brings back way to many possibilities to process quickly.

Larry, exclusions would be nice…but for now, this is where we are.

Anne

11 Jerry BryanJanuary 4, 2010 at 4:18 pm

Anne, re: #10, could you explain something I’ve never understood about the wildcard restrictions. Why will the search engine accept (for example) a blank first name and Smith as the last name, but will not accept J* as the first name and Smith as the last name?

The stated rationale is that J* will bring back too many possibilities. I would argue it’s just the opposite. J* will brink back many fewer possibilities than will the blank. So I end up putting in blanks for the first name, Smith for the last name, and scrolling through a gazillion matches, even with an exact search. So the system is more overwhelmed than it needs to be. And more importantly, I’m more overwhelmed than I need to be. Wouldn’t it make sense to put in J* for the first name and to bring back fewer matches?

In any case, I’m excited to try the new flexibility to see how much it helps.

[...] Ancestry Search: Improved Wildcard flexibility Ancestry Search: Improved Wildcard flexibility [...]

13 Andy HatchettJanuary 4, 2010 at 4:51 pm

Jerry RE: #11

With the first name blank there is no search on the first name field at all.

So the load on the servers is much, *much* less.

14 Anne MitchellJanuary 4, 2010 at 6:54 pm

Actually, J* brings back more records for processing than searching for nothing.

But let’s back up a second and start from the beginning on what happens when you do a search. And I’m going to ignore all the steps we take for efficiency and just try and describe what happens in general terms.

We don’t store our records in large relational database tables and run queries against those tables. No major search engine of any size does that. Instead, each record in our collections, and there are billions of them, has a set of fields that is indexed.

Most structured records have at least a first name, a last name and a primary location indexed. When we index these records, we create lists of record #’s for each of these.

So if we have a record for a John Smith who was born in Georgia, and the record number is 3890825 we add that number to first name list for John, the last name list for Smith, and a list of Georgia birth places. And we do that for every record we have. So when we are done indexing all of our records, we have many, many lists of record #s. And again, this is how search indices are set up.

So now we’ve got these lists of record numbers for every first name out there, for every last name out there and for every birth place out there. We also create lists for soundex possibilities of last names as well, and a few variations.

So let’s say you do an exact search on just the last name Smith who was born in Georgia.

Our search engine pulls all the record #’s from the Smith last name list. Then it pulls all of the record #’s from Georgia birth place list.

Since this is an exact search, it then finds all the record numbers that appear in both lists and displays them to you.

OK, now let’s say you add J* as a first name. And it’s exact. The search engine pulls all the record #s for Smith just like before and all the record #’s for Georgia just like before. Then it would have to pull the record numbers for every first name list that began with a J. Think of how many first names in our data collections begin with the letter J. It’s a lot. So you now have 3 lists: one for all the Smith’s. One for all the Georgia birth places. And one for every record that has a first name that begins with J. We’ve got many millions to work through here.

Once, the search engine has the three lists, one for last name, one for first name and one for location, it would look for record numbers that appeared in each of three lists. And because this is an exact search, the record number must appear in each of the three lists. There are a lot more records to examine here. By having you put at least 3 letters in the name, we can limit the number of records that have to be pulled. The “J*” scenario is doable, and it actually works quickly most of the time depending on what letters and other criteria are used, but it will slow down response time in displaying results.

I suspect I may have confused some of you, and helped a few others. I’m more than happy to try and explain this more if anyone is interested.

Anne

15 Ron LankshearJanuary 4, 2010 at 7:31 pm

Thank you Anne – a wonderful New Year gift.
I remember we discussed wildcardz on one of your other blogs a while ago.
I did notice the change last week when by mistake I searched with 3rd letter as ? and got hits.
The ? for first letter is great as I find it easily brings up Lankshear problems like Fankshear and Rankshear which took me a long while to find before this change. Well done!

16 uberVU - social commentsJanuary 4, 2010 at 8:24 pm

Social comments and analytics for this post…

This post was mentioned on Twitter by wychwoodnz: RT: @Ancestrydotcom: Ancestry Search: Improved Wildcard flexibility http://bit.ly/5KPUqY (Sweet – can have wildcard * at beginning now)…

17 Jerry BryanJanuary 4, 2010 at 9:32 pm

Anne re: #13, much thanks for this excellent explanation. I’m old enough to remember the database structure you are describing being called an inverted database. I don’t know if it’s still called that or not, but obviously the concept is still around.

In general, inverted databases provide for extremely fast searching – much faster than relational databases. I worked with such a database back in the 1970′s. What I don’t remember, however, is how or if the database I worked with supported wild card searching.

It seems to me that the way to make the searching I’m talking about fast with your current structure would be to add some additional indexes that we as users would never see. For example, you could have an index for all the A first names, for all the B first names, etc. You might even have to have indexes for all the Aa first names, all the Ab first names, all the Ac first names, etc. It would be a lot of indexes, but it would be doable, and the result would be some very fast searches with wildcards such as J*.

The other approach would be something like as follows. Suppose I did a search for J* Smith born in Georgia. Then the search engine would do the search for Smith born in Georgia as you already described when the first name is blank. There would be only two indexes involved in the search, not three. Such a search would run no faster and no slower than if the user hadn’t typed in J*. But as a part of displaying the results, use the J* as a filter and omit Andrew Smith, Benjamin Smith, Carl Smith, etc. from the display.

18 Judy KayJanuary 5, 2010 at 2:06 am

This is very welcome.

Though the limitation on three non-wildcard characters is unhelpful with short surnames – I would have liked to be able to search for

?ay

but you still don’t allow this. Pity.

19 KarenJanuary 5, 2010 at 3:44 am

I hadn’t read the post about the change before I tried a wildcard search today, on the off chance it might work.

I was looking for Ladimer knowing there were various ways of spelling it I enter L*m*r and it produced spelling variants I had not thought of.The name isn’t common in England so this helped both with census and BDM.

I now have a new census record and the spelling of the surname favour by the family was Ladimir.

20 Lorine McGinnis SchulzeJanuary 5, 2010 at 5:57 am

I just blogged about how much I love this new capability. I gave a few examples too that I used while playing with it yesterday.

http://olivetreegenealogy.blogspot.com/2010/01/new-wildcard-search-on-ancestrycom.html

21 Randy ParrishJanuary 5, 2010 at 6:16 am

This will definitely make it easier to search for people. Thanks for implementing this. :)

22 Jim LivermoreJanuary 5, 2010 at 8:12 am

Anne,

Thanks for the detailed explanation of the process. However, I’d still like a bit of clarification on one point I mentioned. Your search engine has no problem returning results from a single letter as a given name:

H Smith might return

L H Smith
Sandy H Smith
H Eugene Smith
C H Smith

and so on. How is this any less stressful on servers than H*?

23 Deb HJanuary 5, 2010 at 8:18 am

I’m with Jim in #7. I’d been hoping for a wildcard search that wouldn’t require a minimum of 3 characters. However, I did appreciate (but didn’t understand!) Anne’s explanation. Maybe we draft Jerry to come up with a search code!

24 Jerry BryanJanuary 5, 2010 at 9:20 am

I’ll take a crack at answering #21, based on Anne’s earlier explanation.

In order to search for H Smith, the search engine makes two lists of records: 1) all records where the first name contains exactly H (including things like your Sandy H example), 2) all records where the last name contains exactly Smith. The results presented to the user are the records that are in both lists.

In order to search for H* Smith, the search engine would make two lists of records: 1) all records where the first name starts with H, 2) all records where the last name contains exactly Smith. The results presented to the user would be the records that are in both lists.

Superficially, the two different searches seem to be about the same. Based on Anne’s explanation, it appears that the performance problem associated with the H* search would be simply that the H* list would be much longer than the H list. Indeed, the H* list would be much longer even than the Smith list.

25 Don KirkmanJanuary 5, 2010 at 12:41 pm

Wouldn’t fewer than three non-wildcard characters be of even more benefit
for names than for other kinds of data? ISTM we search for names far more than for other things, yet the old restriction remains for names, apparently.

26 BromaelorJanuary 5, 2010 at 1:40 pm

Again another positive enhancement to the the system. Keep it up!

27 JUDYJanuary 5, 2010 at 2:23 pm

FOR ONCE ANNE I CAN SAY WELL DONE!

i’m not going to comment on the 3 letter limitations as others are doing so although i too would like just one letter. and yes i did understand your explination it was clear enough for me and i am dyslexic. this is the type of answer …a full one …. that i would expect to see here.

but i will bring up once again another point in the hope we will get a full explination just as you have on the 3 letter limitation on why there is that awlful unhelpful and unneeded FUDGE FACTOR of +/- 3 on new search for all exact searches.

once again i expect EXACT TO BE EXACT IF I WANT JOHN SMITH 1910 SURREY UK THEN RESULTS RETURNED SHOULD BE FOR JOHN SMITH 1910 SURREY and nothing else. having looked at your explination i can understand it might take longer to pull just those matching 1910 from the 3 lists you mention but as you must have indexed the years anyway and in most cases need to have the 4 list for year anyway why cant we simply have the records pulled for 1910 instead of 1907 to 1913 the list must be shorter returned for 1910. when you concidering in MOST of the bmd for the uk we can pull just a certain quauter (q1,q2,q3,4) anyway. or am i missing the point?

so come on anne an explination for the need for that awlful FUDGE FACTOR on exact searches in NEW SEARCH is long over due.

AND HAPPY NEW YEAR TO ALL

28 Jim LivermoreJanuary 5, 2010 at 2:55 pm

Thanks, Jerry, for ‘taking a crack it’. You may be correct in your analysis. Let us keep in mind this search limitation has been in here ‘forever’ in my years here. Technology, both computer and database, has not stood still. Are assumptions on performance problems based on 10 year old data? Has the performance of such a query even been profiled lately?

29 Martin BriscoeJanuary 5, 2010 at 4:00 pm

That will be very useful.

Now if we could just get the search to stay on Old Search and not keep switching back to New Search at random.

30 DeanJanuary 5, 2010 at 7:25 pm

Invalid or Unauthorized Input Has Been Detected
There is a problem servicing your request—it contains invalid or unauthorized data. The details of the problem have been automatically logged to our servers.
This unidentified “error” correction does not correct the error, and denies me access to my families.

If you feel that you have reached this page in error, use your browser’s Back button to identify the page and data that caused the problem. Then re-enter the information.

31 margaretJanuary 5, 2010 at 8:10 pm

Thrilled to be able to use a wildcard for the first letter.

32 Jerry BryanJanuary 5, 2010 at 9:18 pm

I’ve been playing around a little bit with the new wildcard support, and I really think it’s a huge step forward – really great progress. The three letter limit still exists, of course, but in general it’s nowhere near as much of a limit as it was before. That’s because before the first three letters had to be included in your search field. Now you just have to have three letters *somewhere* in your search field.

I did a couple of experiments that exemplify this. The first example is that I searched for a last name of a*a*a. It’s kind of a strange looking search, and it’s not looking for any of my own families. But the search works and returns results that make perfectly good sense (try it and see!) The search wouldn’t have worked before.

The second example is my own surname of Bryan. Common spelling variations are Bryan, Bryant, Brian, and Briant. There are many more variations than those four, but those are the main ones. I can now search for br?an*. I was not able to do so before because before I was not able to use a ? as the third character.

There are two instances where I think the three letter limit is still a problem. One is for very short names. The other is if you want to search for something like j* smith.

There’s one other situation that I haven’t investigated very much so far. That’s names that have a prefix or are compound, such as O’Bryan, McDonald or MacDonald, and VanDyke or Van Dyke. My experience with names such as these is not so much that the search engine does a bad job as it is that the search engine does a very inconsistent job. You are never really quite sure what you are going to get. For example, MacDonald may end up being indexed as MacDonald, or it may end up getting indexed as Mac Donald. I’m hoping and expecting that the new wild card support will help a great deal in searching for such names.

33 CONSTANCEJanuary 6, 2010 at 2:35 am

Outstanding improvement.

34 JOHN GROSSJanuary 6, 2010 at 7:49 am

THIS SITE DOES NOTHING BUT RIP YOU OFF. WE STARTED TO DO A SEARCH AND NEVER EVEN FINISHED THE TRANACTION AND BACK OUT AND WAS BILLED ANYWAY

35 Deborah BaillieJanuary 6, 2010 at 12:50 pm

Definitely a much needed improvement. Thanks.
Now, would you consider adding a wild card that represents zero or one character, please, or possibly change the ? wild card to do so. This would greatly facilitate searching Mc and Mac variations as well as double letters when they aren’t always double, and names which may or may not have a space in them.

36 CarolJanuary 6, 2010 at 3:23 pm

RE #7 #17 #22, The limitations don’t help with Chinese names. We have a lot of 2 & 3 letter names. If you wanted to use the name Lee or Li. This is just one of many.

37 John Zimmerman, Jr.January 7, 2010 at 7:33 am

Excellent improvement and announcement to our community. You might think about a very brief statement on the bottom of the search template that comes up when we initiate a search so more people are aware and those of us with weak memories have a quick reminder each time…thank you. jz

38 Maria RostockJanuary 7, 2010 at 10:20 am

Thanks This is just what I have been waiting for.

39 MaureenJanuary 7, 2010 at 3:24 pm

Excellent Article! I’m happy to have this improved functionality, but this post contains some truly helpful examples. I was getting really frustrated, and had abandoned the use of a wildcard because it did not give me the results I expected. Thanks!

40 nre43January 7, 2010 at 5:32 pm

Anne Mitchell
Improved Wildcard flexibility-thanks for the up date

Im new here but,am learning Just found much needed info on my Grandfather …..WOW:-)

41 Ron LankshearJanuary 7, 2010 at 6:36 pm

Anne
I hope you don’t mind But can I comment on a problem with the new UK LMA records

Some of the churches are shown in wrong places
for example
Saint Andrew, Stoke Newington
Borough: Hackney
County: Middlesex

The records are for St Andrew Newington an entirely different church – in South London not North. And if anything should be Southwark Surrey

The street addresses on baptisms are clearly Southwark not Hackney

An Alternate comment has been made but searchers may miss as records are under Middlesex not Surrey

Please could you pass this to people who can fix these index glitches Thank You

42 M GrenzebackJanuary 7, 2010 at 9:58 pm

Everyone seems excited about being able to use a wildcard for the first character–I wonder why it is not working for me? I’ve tried both *renzeback and ?renzeback (and a few other variations), and I get the message, “The wildcard query resulted in too many matches.” Somehow I really doubt there could have been many matches for this….

43 LindaJanuary 8, 2010 at 5:58 am

My family tree is littered with common names and I seem to have spent forever searching for Joseph Brown in 1851. However I still can’t search for ?rown or *rown or for preference *own? and *oun?

I fear this is an ode to the common name!

44 ChagoiJanuary 8, 2010 at 7:51 am

#42 Linda

Strange! I was able to search using Jos* *own on the UK 1851 census and got sensible results.

That was on Old Search with exact matches ticked and exact spelling.

45 Larry Van WormerJanuary 8, 2010 at 9:48 am

Re. message #41. Your problem sounded kind of odd, so tried it myself, and *renzeback worked perfectly. Maybe you are encountering the problems others have seen with specific operating systems and browser versions? (I’m using an up-to-date version of XP, and Seamonkey 2.0.1

46 AmirJanuary 8, 2010 at 1:30 pm

There are some big issues with this ‘fix’ that make it unusable.

Here’s a simple scenario:

1. In new search, if I search for *rightmire, I get the regular “The wildcard query resulted in too many matches” error.
2. If I add a birth location of “Virginia, USA” I used to get some results, but now I get the same error.
3. When I did get results they were summarized by Relevance, which is never useful. If I tried to switch to summarized by category I would get the error again.
4. If I tried to select a category from the list on the left, like Census, I would get the error.

When I tried old search it worked. But old search has so many issues I don’t even know where to start.

So basically this ‘fix’ is useless.

47 Linda JohnsonJanuary 8, 2010 at 6:57 pm

I am trying to find out if this person name and birthdat is correct.
Hi mother name is Pamela Bethely Adams and she was suppose to be born in New Orleans Lousiana. Her mother and father name is Jesse Bethely, and Dorothy Mae Bethely.
This lady was married to a Ralph Adams and I am checking to see if she had a son by the name of Jamie Alan Adams. This person say his borthday i 9/26/1991.
I need to know this information is due to he murdered my grandson in April 29, 2009. He did not even know my grandson and murdered him for unknown reason.
His mother and father suppose to be living in Metarie Lousiana.
Please help me if you can. If this is not his correct name please tell me what is her son or sons name. Yes, this ishis mother because she and her husband siged the bonding paper tis past November 22, 2009.

48 JUDYJanuary 9, 2010 at 4:27 am

HI ANNE

i was just trying to search on the public AMT trees

there is a problem

i was looking for the surname DENT exact match in old search in ENGLAND WESTMORLAND this threw up over a 1,000 hits.

so i decided to cut it down and added in the search for KENDAL

and what did i get

NOTHING

AND THE RESULT WAS STILL

NOTHING

EVEN IF I TOOK OUT THE WESTMORLAND

As i have a number of DENT ancestors whom are from KENDAL IN MY OWN PUBLIC TREE i should have pulled up them at least

i then tried a genral search leaving both the names blank and again searching for ENGLAND WESTMORLAND KENDAL and ENGLAND KENDAL and still got NOTHING

even tring using diffrent combinations using a * or ? on the word KENDAL resulted in no matches

so the obvious conclution is that there is a gremling in the system making ‘kendal’ a non word

49 Myra TomkinsonJanuary 9, 2010 at 8:15 am

One of my family names is extremely difficult to track. Modern spelling is Bewley. In the 1891, 1901 & 1911 censuses I have found my family transcribed as Beioley. However, searching the bmd with the phonetic switch on has brought the total of different spellings to 29 and I have not been able to find my Bewley family with any certainty in the earlier censuses. Do you have any suggestions as to how I may be able to use the updated wild card facility, please?

50 Jerry BryanJanuary 9, 2010 at 9:09 am

Re: Myra #48. That’s going to be a tough one. My first instinct was to try b*l*y. But that has two problems. One is that there are far too many matches (e.g., Bailey). The other is that b*l*y crashes New Search. That is, after the initial search you are in Sorted by Relevance view. Upon choosing the Summarized by Category view, you get the “We’re sorry but Ancestry.com is temporarily unavailable” message. This problem may or not be repeatable for others, but it’s 100% repeatable for me. No other searches seem to have the same problem, and Ancestry.com manifestly *is* available.

So I switched to Old Search so it wouldn’t crash and tried be*l*ey. There were still far too many matches. In order to reduce the matches further, I would have to know more about some of your Bewley family members – given names, birth dates, birth places, etc. If enough of that kind of information were available, it might be possible to go back to the b*l*y search to be sure to find all the spelling variations.

Good luck with your research. Sorry I can’t be of more help.

51 JeanJanuary 10, 2010 at 2:07 pm

I am glad for the wildcard but do not like the look of the new search page. The header info of the person leaves out a lot of basic info that was there before. This info such as spouse, parents and family members helped narrow down selections when going thru the large number of hits on the searches. Please put this back.

52 LauraJanuary 10, 2010 at 6:38 pm

YAY! I was finally able to test out some names using this new capability. The Brunschwilers in my husband’s family NEVER have their name correctly on census records (not necessarily Ancestry’s fault, since the writers of the census just wrote whatever they wanted, one time it was Bruni). But I needed the 1920 census and could never find it. Anyway, I typed Br*ler and sure enough, the VERY FIRST ONE is the one I want (Bruschoviler). THANK YOU! Off to test the next name!

53 VirginiaJanuary 11, 2010 at 10:34 am

Thanks for the improved wildcard search.

Recently, everytime I use Edit on my search, it comes back with Exact checked for all entries. It’s tiresome to keep changing this back to what I had for the previous search.

54 Gen JonelyJanuary 11, 2010 at 3:25 pm

Helpful clarification of search options.

55 Polly RuberyJanuary 12, 2010 at 7:29 am

Thank you for this great improvement – I’ve already found quite a few “missing people” using it.

However there is one place where it doesn’t work and where it would be a great help if it did. And that is in the English & Welsh GRO birth and death indexes from 1916-2005 (which are great BTW!).

This is because for the period 1916 to 1966 no full second names are recorded, but afterwards they are listed in full.

So it would be great to be able to search the whole database by using “Adam A*” but this is not allowed.

Thus to get all the results, both “Adam A” and “Adam Afullname” you have to search just for Adam, which (with more common names than my example) greatly increases the number of results one has to wade through.

[...] that 2010 is going to be an exciting year for Search at ancestry.com. As you know, we launched expanded wild card functionality at the beginning of this year. But that was only the start of things to [...]

57 Jackie KrearJanuary 12, 2010 at 4:09 pm

Keep working to get even MORE (like two letters and a wildcard)… and wildcards on BOTH ENDS (cause searches on the INTERIOR of words is NOT new science).

But thanks for small improvements of any kind.

58 Nan HarveyJanuary 13, 2010 at 11:03 am

This is absolutely wonderful. Maybe I can find my Bromagem (Brumigen, etc.) ancestors more easily.

59 ElizabethJanuary 16, 2010 at 12:32 pm

This is great news and I am excited about being able to embark on many new searches!

60 Ron LankshearJanuary 16, 2010 at 5:14 pm

I am searching with
?ob*ns
for Robins or Robbins which sometimes also end ens or ans
and may start with D or other letters

?ob*ns seems to be in the terms of the new wildcard function

But for a week or so whilst I get results
There is also a message with red/pink background

“Due to current technical difficulties, only partial search results are shown above. Please try your search again later to see full results.”

I thought temporary but seems to be permanent now and appears when I try “complex” wildcard searches

61 claireJanuary 17, 2010 at 2:36 pm

Yeah on the new feature…and a request. If possible the feature I would love added is the option to sort the search results by the column headings.

Often I get hundreds of results. If I use too many filters I sometimes lose the very result I am looking for. The option to sort all the results by birth date, place, or surname would be a fantastic time saver!!! That way I could sort the information by the column I am most certain of. That way I can reduced the number I need to look through and, at the same time, keep in all the results that may have errors…misspelling wrong years, etc.

About the Ancestry.com blog

Here you will find informational, and sometimes fun, posts from the folks behind the scenes here at Ancestry.com. We hope you’ll notice just how passionate we are about family history and about the products we’re building to help connect families over distance and time.

Visit Ancestry.com
Notifications

Receive updates from the Ancestry.com blog Learn more