Hi Dirk, > > > 2. Extend the searching in not char fields with: > > != value results in where fieldname <> value > > <> value results in where fieldname <> value > > < value results in where fieldname < value > > <= value results in where fieldname <= value > > > value results in where fieldname > value > > >= value results in where fieldname >= value > > value1-value2 results in where (fieldname >= value1) and > > (fieldname <= value2) > > value1- results in where (fieldname >= value1) > > -value2 results in where (fieldname <= value2) > > This works for numeric, date, timestamp fields! > > > It is directly written into the form field by the user? Yes, it is.
> No select tag containing comparison operators or something > similar? Would it be possible to support that, too? > Currently the 'search algorithm field' allows to select between '=' and > 'like' queries. That is already the choice of an operator. Yes, but the user do not have a choice. But i think we should build a new search algoritm to switch the extension on and off. > Wouldn't it be possible to add at least simple comparison > operators here? This would make it possible to add such > a operator select tag on the search page. The options could > have lables like 'greater than', so even people who don't > know the '>' would immediately be able to use it. Do you think about a separate parameter for the operator? Something like searchoperator_0_1="<=" as parameter of the form? > > I think you decided to offer it just for non char fields > because otherwise you would have parsing problems. What does > 'RRR-YTR - UYTF' mean? > > = 'RRR-YTR - UYTF' ? > >= 'RRR-YTR' AND <= 'UYTF' ? > >= 'RRR' AND <= 'YTR - UYTF' ? > > If you separate the operator from the operand again, that > will be no problem any more. You could offer that also for > char fields. The only problem would then be the between-and > queries. Maybe an optional second operand field for this case? In the moment only the last/first search parameter (e.g. parameter with name search_0_1) is used for the select. Maybe we should parse all parameters with the same name to build the select. Problem is the searchmode and search algorithm, there is only one for each parameter. Regards, Henner ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
