Carlos
Thank you for your good suggestion .. unfortunitly I have inherited a system that has multiple relational tables and it goes something like this
- Code: Select all Expand view RUN
Bitem Table (pk) Project_number '27'
Brevision Table (fk) BINumber '27.01', '27.02','27.03' ... multiple line items concatenated by project_number and .01,.02,.03,04
Bitem Table (pk) Project_Number '271'
Brevision Table (fk) BINumber '271.01', '271.02','271.03' ... multiple line items concatenated by project_number and .01,.02,.03,04
Project_Number is the primary key and BINumber is the foreign key .. where I got into trouble was using the Like% operator :
cSQL := "Select * from BRevision where BRNumber like '"+ltrim(str(nProj))+"%' Order by BINumber"
As you can see .. the like% operator would have returned both records and there are additional relational tree's from Brevision on other foreign key's in tables Corposal and the Citem table which uses the same root foreign key concatenated rule as root+.01,.02,.03, etc ..
The results I got did not seem different from the original program I am replacing .. all the totals seemed to add up, only when I looked at the oRs:RecordCount() did I realize I was returning a ton of rows at a horrible performance price. After reviewing the recordsets did I realize my error using Like% on the root and the
wisdom of the origional designer by using a . to delineate the foreign key.
At that point I had no choice but to Substring() out my query and add the . to the Primary key in searching for the relational BINumber foreign key.. and the result was this :
- Code: Select all Expand view RUN
nLen := len(ltrim(str(nProj)))
nLen++
cSql := "Select * from BRevision where Substring(BRNumber,1,"+ltrim(str(nLen))+" ) = '"+ltrim(str(nProj))+".' Order by BINumber"
As far as performance, and the full table scan ... I have not tested it on a slow or VPN connection and I do not know if I will gain any better tuning, but I definitely will return less rows and an accurate relational result in the case of a primary key overlap.
Thanks
Rick Lipkin