locked
Details Picker search text is case sensitive RRS feed

  • Question

  • I am using a details picker that has a datasource (choices) set to a WCF query. I get results when there is a case sensitive match. Is there any way to specify that the auto-complete should be case insensitive?

    case sensitive search


    JeffJ


    • Edited by JeffLS123 Thursday, July 16, 2015 3:01 AM
    Thursday, July 16, 2015 3:00 AM

Answers

  • Jeff,

    The built-in LS search method, I believe uses Linq .Contains() method in the middle tier.  Turns out this method behaves differently depending on whether it executes in a database context or .Net context.

    See:http://stackoverflow.com/questions/3360772/linq-contains-case-insensitive

    From which I gather: With Linq to SQL the .Contains() translates into LIKE %searchTerm% and the case sensitivity depends on the database (insensitive by default).  In .Net context, it's hard or impossible to do case insensitive .Contains() in a consistent way.  Therefore it may be true to say that the built-in search is always case sensitive for RIA POCO entities.

    Perhaps this is because the LS generated code may not implement StringComparison nor toLower as Hessc suggested, but I could be wrong.

    Perhaps some folks with more Lightswitch-WCF experience can help you determine if there is a way to force the built-in search to be case insensitive.(?)

    Josh



    • Edited by joshbooker Friday, July 17, 2015 2:30 AM
    • Marked as answer by Angie Xu Monday, July 27, 2015 2:09 AM
    Friday, July 17, 2015 2:25 AM

All replies

  • In your WCF query, implement StringComparison or turn the strings toLower or toUpper before comparing them.
    Thursday, July 16, 2015 3:13 AM
  • Thank you for the response. It seems that the string comparison is happening on the client. When I get to the third character  ("tes" in this case) a query request is sent to WCF and several records are returned including one record that contain "Test" with a capital T. However, is does not display as an available option as the image above shows.

    JeffJ

    Thursday, July 16, 2015 3:20 AM
  • I don't think the comparison is happening on the client.  I would bet that your query does not support case insensitive comparison by default, so you need to implement StringComparison or change the strings to upper or to lower before comparing them.  Post your query code and we can probably help.
    Thursday, July 16, 2015 3:35 AM
  • The search string is not passed to the WCF Query. The list is small so all records are returned to the client.

    public IQueryable<TransferLocationInfo> ReadTransferLocations(int? SupplierId, string  LocationType)
            {
                TransferLocationInfo Transfer = new TransferLocationInfo();
                List<TransferLocationInfo> TransferList = new List<TransferLocationInfo>();
                TransferList = Transfer.ReadTransferLocations(SupplierId, LocationType);  //returns all transfers
                return TransferList.AsQueryable();
            }



    JeffJ

    Thursday, July 16, 2015 3:51 AM
  • Are you sure all records are on the client?  It looks in your screen shot that you're breakpoint is in server code.  So, while the RIA backend may return the row, the LS middle tier (still server-side) will apply the search string and restrict case-sensitive before rows are returned to client. 

    To test this, try a browse screen on the same entity with search enabled.  Fire up Fiddler and do a search.  This uses the same visual collection .search method used by the details picker.  In fiddler you will see the exact odata filter request and response data.

    HTH,

    Josh 

    Thursday, July 16, 2015 1:30 PM
  • The odata query is:

    http://localhost:5235/WCFRIA_ReservationsData.svc/ReadTransferLocations()?SupplierId=3&LocationType='StartLocation'&$top=15&_search=tes 

    which is returning 

    {"odata.metadata":"http://localhost:5235/WCFRIA_ReservationsData.svc/$metadata#TransferLocationInfoes","value":[]}

    It does seem to be filtered somewhere between the WCF return values and getting back to the client. Is there a place to specify case insensitive on the LS middle tier?


    JeffJ

    Thursday, July 16, 2015 2:03 PM
  • Jeff,

    The built-in LS search method, I believe uses Linq .Contains() method in the middle tier.  Turns out this method behaves differently depending on whether it executes in a database context or .Net context.

    See:http://stackoverflow.com/questions/3360772/linq-contains-case-insensitive

    From which I gather: With Linq to SQL the .Contains() translates into LIKE %searchTerm% and the case sensitivity depends on the database (insensitive by default).  In .Net context, it's hard or impossible to do case insensitive .Contains() in a consistent way.  Therefore it may be true to say that the built-in search is always case sensitive for RIA POCO entities.

    Perhaps this is because the LS generated code may not implement StringComparison nor toLower as Hessc suggested, but I could be wrong.

    Perhaps some folks with more Lightswitch-WCF experience can help you determine if there is a way to force the built-in search to be case insensitive.(?)

    Josh



    • Edited by joshbooker Friday, July 17, 2015 2:30 AM
    • Marked as answer by Angie Xu Monday, July 27, 2015 2:09 AM
    Friday, July 17, 2015 2:25 AM
  • Thank you all. I have changed to a custom control and used a dropdown instead of the details picker since I could not find a suitable solution.

    JeffJ

    Sunday, July 19, 2015 1:04 PM