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

This seems to be the same bug I found

See: http://www.datasprings.com/Products...fault.aspx

Not applying the criteria line to the query if it's empty won't solve the problem if you search for field x doesn't contain y. Now you want to find users who haven't filled in the profile field y. Which again doesn't exist in the database

I think the problem can be solved by building a temporary table with all the properties in it. If a property for a user is missing an empty field must be created.

It's difficult to explain....


Regards,


Jan Alwin

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 guys...

Well we are actually changing the way this is coded in the next version (this is after the patch for the location on field criteria though which is a seperate issue). Even with the updates though I will still need to review this to see if its going to fix the problem with the filter. We will be creating a view/stored procedure similar to the same right outer joins are we are using in the recent Dynamic Forms query that we recently posted. This will also speed up the process for larger implementations as well as improve searching...

On this issue though...

In your example I am assuming 'HomeAddress' is a search field setup correct? 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? 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, 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?).

Also, if you are not satisfied for any reason (and you didn't purchase a package with source code) we can quickly issue you a refund, just let me know.


-Chad

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 equals 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 %%

Ok, I am going to do some testing with this. First I just want to make sure its coming in as null if you leave the field blank within the core so that I can confirm this on our installation etc... Second, if this is the case we will research a fix but need to test against several scenarios (this filter and search criteria filter is very touchy so the moment we change this for a certain field type it might not always be happy in other implementations or situation )

So, this would only be added if the user entered nothing right? Because otherwise if they entered "1234 ABC Street" then the filter would look like:

AND (HomeAddress = '1234 ABC Street' or IsNull(HomeAddress)) which would then always return the table row regardless of what the user entered. So this would need to be in place only when the user filled in nothing correct?

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.n...fault.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 available 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