1.  I don't see a missing "+" before DateReceived.
"CKeyField = By QS0 + ";" + Job Name + ";" + Merchant + ";" + Status  + ";" + Street Name  + ";" +  District  + ";" + City0  + ";" + Builder  + ";" + Merchant REF" + ";" + DateReceived
2.  Why not search in the DateReceived element?
3.  How about a Universal Search vs. a complex Keyword field?
4.  What is triggering the filling of the Keyfield.  If this is from a line item on a subform, it looks like it will always be overwritten, so only the last line content will be there.  Should this be "CKeyField += ... to allow all lines to be there?

For a moment, forget what has been done, but explain please, what you are trying to do?

I have been totally confused about the structure here, and usisng Skype, I finally got a chance to look at this construction. 

Among other things, each record has a KeyWord element that is populated with values from many elements.  There are no mulitple sub records linked to a parent record, so the values in the KeyWord element are not overwritten.  The subrecords are added at the subform level, not from the parent.

The "Parent Form" is more like a menu form.  There is only one record.  There is a RetrieveSpecElement on that form that is filled with a Retrieve Spec value that looks into the other database KeyWord element for a match, and shows the matching retrieved records in a sub form, table view.  This element is a Parent Link element.  The Child Link element is the KeyWord element.

The current search problem is that there are multiple dates in the KeyWord element: elements like DateCompleted;DateReceived;DateShipped, etc.  If a date for DateReceived is entered into the RetrieveSpecElement, the records that come back could be any one of those DateElements, there is no way to say DateReceived, it is only matching any string that matches that date.  And there is no way to put in a normal date range like 3/15/07..8/20/07.  But at least I now have a better understanding of the problem.

I don't have access to Sesame now and haven't tried this yet, but this is my current thinking   ....  put a formula into the RetrieveSpecElement.   I know that DateReceived is the seventh element in the KeyWord element.  The KeyWord element is just an array, So put in a formula that says, Take the value of the seventh element in the array and deal with that.  So the formula would = seventh array value, or the formula could compare the seventh element to see if >@date-30 for the last 30 days.  Could do a similar approach if looking for DateStarted.  Determine the array element that holds DateStarted, and extract that value for the formula.  The array to look at is the KeyWord element.

I hope there is enough info here to try that out.  And I think that the ArrayElementPosition is possible with version 1.  I may be using wrong terminology for ArrayElementPosition, manuals not available.

You're welcome.

Everyone here helps one another. 
I have received my share of help, also.

Still need a working solution ....... I think extracting the value out of the KeyWord array will work.

Sorry if I was not clear.

I mentioned my own confusion until I saw the application first hand.

Parent form has a text element, I called it RetrieveSpecElement.  This is the ParentLink element in natural relationship.
Subform has a KeyWord element that has an array of element values from the subform.  This is ChildLink element in natural relationship

Date from sub form is returned to Parent form, for Read Only, but much better than report.

From the parent form, a string is entered into RetrieveSpecElement.  It pulls up a table view list of records in the subform that have a matching value iin the KeyWord element.  From that tableview, a record is selected, a "Copy Record" button on Parent is clicked and data from that sub record is copied to elements on the Parent Record to be viewed with other form features.  Report is not practical here.

The problem is retrieveing the correct data element from the KeyWord array.  If 9/4/07 is entered as a value, then records may come up that had ShippedDate = 9/4, StartDate= 9/4, and CompletedDate= 9/4 because they all have 9/4/07 somewhere in the KeyWord element.  If the 9/4 is supposed to be the CompletedDate record, then CompletedDate position must be known as the value to extract, ie: the seventh value in the KeyWord.

I have not seen a retrieval like this before,  It is very creative.  It may have some other issues, but I think it has a lot of potential use.  I would not have designed this in the same manner, but we all have our own approach to solutions.  So, trying to work with his existing design, this is an attempt to make it work.

1.  You are right, the link is Relational

2.  I know that the normal method of linking would be using text elements, not KeyWord elements.  And this may not work.  As noted above, this is not my design, but sometimes some surprising results when you experiment.  In this case, if the Keyword element on the subrecord works, and it seems to so far, it may open some doors that were not anticipated.

3.  I wonder if you and I may be using terminology differently also.  When I am talking about a ChildLink, I mean the element on the subrecord that may contain a match that is defined by the value in the element on the Parent record, which I referred to as the RetrieveSpecelement.  In any case, at first look, you say "What is going on here?"  But after you dig in and do an autopsy, you see a very creative approach.  Whether this is an accident, or be design, I did not pursue.

4.  The dates in the KeyWord element, on the Child subrecord,are strings.  Here is an example of that element in two records:
Quote:
.  (Yes, that 1899 is an error). 
In this case, there are two dates that are actual,in the second and third positions.  One other date is empty, in the fourth position.  Entering 2007/09/12 into the RetrieveSpecelement on the Parent record will result in both of these records showing up in the tableview subform.  But it is desired to only show records if the third position has the date of 9/12.  That is why I am suggesting grabbing the value using a formula that  gets the value of the third position in the "array".

5.  None of the "normal" rules about delimiter apply, because we are not using a delimiter in the RetreiveSpecElement, we are only using the string "2007/09/12".  The "delimiters" in the Child KeyWord element are the normal semicolons used for KeyWord elements.

6. Again, I have probably added more confusion.  That tends to happen when the complex is put into words without visual aids.  The best way to understand this is to look at it.  Again, unconventional, may not work in all cases, but is working good right now.  Just need, in some cases, to be specific about the element position to look at, vs. using the whole KeyWord values string as normally expected.  It's not my database to share, but maybe drastixnz will share a screen shot of the Parent record showing the keyword element in the subform.  That may be helpful.

7.  And, although interesting, I think that I would eliminate the Parent record completely.  Would make the subform records a normal top level database, and would make multiple views, form and tableview, for the records, using the normal retrieve specs.  And move a lot of the buttons on the existing Parent form to the new forms needed when the subforms become top level forms again.

Confused enough?  Enjoy, thanks for your explanations of "normal" behavior.