[ic] building OR statement in mysql for query tag notconsidering all options

Aaron interch at hazenet.net
Fri May 27 15:01:28 EDT 2005


On Friday, May 27, 2005 1:16 PM
Racke, racke at linuxia.de wrote:
> 
> 
> On Fri, 27 May 2005 12:29:36 -0400
> "Aaron" <interch at hazenet.net> wrote:
> 
[snip]
> > Returning this variable to the screen would for example 
> give you the 
> > following query (line breaks added to make it easier to 
> read): SELECT 
> > * FROM services
> > WHERE adv_user = 'Acme Services' 
> > AND brand = 'General Brands' 
> > AND contract = 'Acme' 
> > AND date BETWEEN '20050101' AND '20050527' 
> > AND completed = '1' 
> > AND ( type = 'Buff-Floor' 
> > 	OR type = 'Facade-Pressure-Wash' 
> > 	OR type = 'HVAC-Maint.' 
> > 	OR type = 'Lighting-Maint.' 
> > 	OR type = 'Refrigeration-Maint.' 
> > 	OR type = 'Strip-Floor' )
> > ORDER BY date, store
> > 
> > So only types matching "Buff-Floor" are returned when passing the 
> > variable holding this information to the query tag.  Copying this 
> > output text and entering that directly into the query tag gives 
> > results for other types as it should.  If I remove 
> Buff-Floor from the 
> > options selected on the form on the previous page, then the second 
> > option like 'Facade-Pressure-Wash' will be returned and no others.  
> > Only the first is considered and there are no errors.
> 
> One possibility to trace this down is enable debug within 
> Interchange and enable DataTrace. This will write all DBI 
> scatter to the debug file.
> 
> DebugFile /var/log/interchange/debug.log
> DataTrace 1
> 

Thanks for the suggestion Racke.  I enabled debugging and don't know
exactly what I am seeing, but here is the appropriate snip from the
debug file:

    DBI::db=HASH(0xa7bf810) trace level set to 1 in DBI 1.39-nothread
(pid 29959)
1   <- FETCH('NAME')= [ 'code' 'adv_user' 'brand' 'contract' 'store'
'division' 'region' 'area' 'type' 'sub_type' 'charge_type'
'charge_qualifier' 'cost_type' 'cost_qualifier' 'requested_on'
'requested_by' 'requested_date' 'request_info' 'date' 'timeh' 'timem'
'timeap' 'date_faxed' 'date_entered' 'date_confirmed' 'date_canceled'
'date1' 'date2' 'contractor1' 'contractor2' 'trk1' 'trk2' 'confirmed'
'confirmed_by' 'canceled' 'canceled_by' 'notes' 'completed' 'billback'
'chargeback' 'no_show' 'no_show_con' 'no_chemical' 'chemical_type'
'chemical_used' 'chem1' 'chem1_gals' 'chem2' 'chem2_gals' 'chem3'
'chem3_gals' 'labor_hours' 'num_persons' 'billed' 'billed_inv' 'paid'
'paid_inv' 'adv_billed' 'adv_billed_inv' 'emailed_to_homeoffice'
'emailed_to_contractor' 'notified_of_receipt' 'charge' 'cost'
'follow_up' 'super_override' 'override_by' 'override_date' ] at DBI.pm
line 1940
1   <- fetch= [ '103194' 'Acme Services' 'General Brands' 'Acme' '1234'
'1' '10' '100' 'Buff-Floor' '' 'each' '1' 'each' '1' '20050523' '' '' ''
'20050102' '' '' '' '20050523' '20050523' '' '' '' '' 'ralph_burns' ''
'1000004503' '0' '0' '' '0' '' '' '1' '0' '0' '0' '0' '0' '' '' '' '0'
'' '0' '' '0' '0.00' '0' '0' '0' '0' '0' '0' '0' '0' '0' '1' '72.00'
'55.00' '' '0' '' '' ] row1 at DBI.pm line 1940
1   <- FETCH('NAME')= [ 'code' 'adv_user' 'brand' 'contract' 'store'
'division' 'region' 'area' 'type' 'sub_type' 'charge_type'
'charge_qualifier' 'cost_type' 'cost_qualifier' 'requested_on'
'requested_by' 'requested_date' 'request_info' 'date' 'timeh' 'timem'
'timeap' 'date_faxed' 'date_entered' 'date_confirmed' 'date_canceled'
'date1' 'date2' 'contractor1' 'contractor2' 'trk1' 'trk2' 'confirmed'
'confirmed_by' 'canceled' 'canceled_by' 'notes' 'completed' 'billback'
'chargeback' 'no_show' 'no_show_con' 'no_chemical' 'chemical_type'
'chemical_used' 'chem1' 'chem1_gals' 'chem2' 'chem2_gals' 'chem3'
'chem3_gals' 'labor_hours' 'num_persons' 'billed' 'billed_inv' 'paid'
'paid_inv' 'adv_billed' 'adv_billed_inv' 'emailed_to_homeoffice'
'emailed_to_contractor' 'notified_of_receipt' 'charge' 'cost'
'follow_up' 'super_override' 'override_by' 'override_date' ] at DBI.pm
line 1944

[snip 12 more lines same as last one]

1   <- fetch= undef row13 at DBI.pm line 1944

This coincides with the number of results that ARE returned, but not the
number of results that SHOULD be returned.

Direction? Ideas?
Thanks in advance.

> Bye
> 	Racke
> 
> 
> -- 
> LinuXia Systems => http://www.linuxia.de/
> Expert Interchange Consulting and System Administration 
> ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
> 

-- 
Aaron


More information about the interchange-users mailing list