Hello

I only bought this product today and have discovered a critical bug that makes it practically unuseable.

The problem is the way you handle your search criteria, in that you force the criteria to be included even if the user enters no search value for that criteria line. Eg. [LastName] like 'Reid' and [HomeAddress] like '%%' - I only entered a value of Reid for lastname, nothing in HomeAddress.

If you create a custom field and the user does not fill in that field, DNN does not create an entry in the UserProfile table for that property.

By forcing your search criteria to include all fields, you are forcing the query to look for a value of [HomeAddress] like '%%' and because the property doesn't exist at all on some records they are not returned, even when [LastName] like 'Reid' is true.

My suggestion is to simply not apply the criteria line to the query if it has not be populated with a search value.

Hope all that makes sense!

Moving on though, could you please give me an idea of how long this will take to fix, because I am going live in a week and whilst I think this product is great it is unuseable in it's current form and I will need to consider other options and a refund if you are unable to rectify the problem in time.

Thanks for your time.

Regards

Kerry Reid

Yes it would solve the problem, I think the only other thing you would have to change is the "is empty" operator.

You have to make the "is empty" operator search for field = "%%" and IsNull(Field) .

The fact is that in it's current presentation, unless you use only one search field or you make your profile data entry and all custom fields in it mandatory, the search results returned will be wrong and not include all the correct records.

Edit: Just reread your reply, your 1st example was Field Does not Contain "Y", would work because if the field record does not exist it can't possibly contain "Y", your 2nd example was what I was referring to above about the " is empty" operator.

Edit2: hehe, I should read everything before I answer, what you are talking about with your temporary table, is called a left outer join in a db query, where it creates null records in the right hand table corresponding to entries in the left hand table. There is more to it that that though, look online for a better explanation.

Hi Chad

First off, for the moment at least, I don't want a refund, because I do think this is a great product with some nice features. It just needs a quick fix.

I'll answer your questions first:

In your example I am assuming 'HomeAddress' is a search field setup correct?  Correct, there are 2 fields set up, surname and homeaddress, surname is a standard field and homeaddress is a custom profile field.

So the search field is setup but the user does not enter anything. Because of this it should return (unless I am wrong) the results for 'Reid' as the other search term but its causing a problem because the user never entered a home address and therefore its null? Correct, it is null because DNN does not create the field record for an empty field. And you have just answered your own question, the fact that it is null, not empty is the problem.

Your query that is created is this: Surname = 'Reid' and HomeAddress = '' whereas what should be created is Surname = 'Reid' and (HomeAddress = '' or IsNull(HomeAddress), obviously thats not the full query with left joins but if you are going to include search terms that have no value you should allow for nulls.

Hmmm.... was the HomeAddress field added after Reid updated their profile? I am wondering if a simple work around would be to update the database one time if a new field is added. No, it is per user, not per field which would mean you would have to run an append query to add null fields as "" to the database whenever a new user is added. Which is also bad because it would waste space in large databases.

otherwise you might end up getting results you wouldn't want if we changed this. Or... If nothing is entered possibly skip the search but if we implemented this it should be an option because not all users would want this (some users might want it to just be contains?). hehe, I only want to use contains and whilst I used eqauls in my example about I only ever tested with contains, the fact is that even if you say HomeAddress contains '%%' it still won't return records with nulls because a null can't contain %%

Hi Chad

I was going to give you a whole example to follow but I'm just too busy at the moment, I gather you have the basic idea of what is wrong though from your last post.

All I need to know now really is that you agree there is a problem and that you are working on getting it fixed.

If you need more info from me then let me know, if I'm honest I would prefer a phone conversation because I can then explain far better than I would on here.

Regards

Kerry

To add to this, the same problem is affecting the filter rules in the settings, whereby if you set a rule and they entry for that person is null they are left out.

Aside from that, has any progress been made on this?

I have the same problem, if you check the following example:

http://bnimexico-com.web12.winsvr.net/Directorio/tabid/60/Default.aspx

and click the link to search for records without including any values for the search fields, only 3 records appear, when in fact I have 6 records that should meet the criteria, but 3 of these users did not include any values for the field KEYWORDS therefore the field is NULL. The query is asking if the string contains a blank space it should therefore ask "is keyword a blankspace or null" AND the rest of the conditions.

Regards,

Eric

Hi guys... Ok, I am proud to report that this issue has been fixed. From now on when you search with the contains clause and leave the field blank it will check both for '%%' and also null values. We should have this patch released as version 2.3 within the next week on Snowcovered. Thanks again for bringing this to our attention!

Also... We are only about 2 weeks away from the 2.4 release of Dynamic User Directory. This version has already been posted as a beta on Beta Springs and is also demonstrated on Data Springs web site on the main user directory page and also the demonstration pages (example one, example two).

The major enhancements include:

• Significant performance improvements related to retrieving the results. We have been running benchmarks between the previous version and are updated scripts for pulling in the data are much faster. Previouslly the data was generated primarily via code and the new method involves very efficient SQL queries, stored procedures, and views. Simply put - its much faster.
• Ability to allow the user to change the page size; also define initial page size, which page size options are avaliable to the user and if the page size control is aligned to the left or the right of the page
• New Maximum Number of results to retrieve - another performance option which will only render the first 'x' number of results to the module. This can be useful if you have a large membership database and want to force the user to search to render fewer records.
• New option to now display the page numbers on the top, bottom, or both the top and the bottom of the results
• New search localization features to allow the ability to localize search conditions (such as begins with, ends with, etc...)
• New search localization features to allow the ability to localize search labels and fields
• Optionally display a results count to the user, showcasing the number of total results displayed along with the listings within that page and current page number etc...

So... In summary... 2.3 includes all known patches and fixes including the issue brought up in this thread related to null values and the user searching using the 'contains' clause. Version 2.4 will be released within the coming weeks pending more testing and updated documentation.

Thanks again guys!

-Chad