Actually, since there are only 2 values, an index may be really problematic, if the table is likely to have a lot of rows
Project a temporary table, index the column and report from it. Dennis McGrath -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul InterlockInfo Sent: Monday, February 15, 2010 3:56 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Order By Index that table. G-luck. Sincerely, Paul D. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Sent: Monday, February 15, 2010 4:48 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Order By This is a strange one: SELECT custno, invno, sdate, idtrans, invamt, payamt, chkno, + chkdate, syear, speriod, batchno,timedate,csr FROM armbatch ORDER BY idtrans ASC shows No Rows (actually 2614 rows exist) SELECT custno, invno, sdate, idtrans, invamt, payamt, chkno, + chkdate, syear, speriod, batchno,timedate,csr FROM armbatch shows 2614 rows The order by is the only difference. IDTRANS is a column that holds the text values, "Invoice" or "Payment" etc.. This program has worked every day for a long time, till today, and this is what I have it traced to. It can't process the data, because it doesn't find any. Can you think of any reason the ORDER BY IDTRANS ASC would be a problem today? One last piece of data for you. Today and once each month for sure, IDTRANS holds only "Invoice" but should that matter? We run this batch program every day to close out our daily financials. Today it failed. Dan
