>>>
>>>I'd be real wary of using TRIM in a SQL SELECT field. If the first value it retrieves ends up 0 length, this can cause all sorts of problems. And since you're doing an order by the 1st column, there should be no need for a separate index, unless you are using it to manipulate the cursor somewhere else in the code. Have you tried to browse the cursor BEFORE you do the report? Is it in the proper order then?
>>
>>Fred,
>>
>>I browsed the table before I did the report. I also tried commenting out the Index lines and running witht he SQL order. No Dice. Funny thing is...when I built the report, I previewed it and it worked well. As soon as I ran the app, error message. Does this happen often in a Group/Total style report?
>>
>
>This is a mystery. I've not run into a report that causes problems if the cursor looks OK before it is run. Are you really sure the report is not using a private datasession? If the cursor looks OK before you run the report, that's the order it should come out in, unless thats not what the report is running from.
>
>>BTW, I put the TRIM() in the SELECT statement for a very good reason: due to some users amazing ability to hit the spacebar a few times before they enter data, the '=' part of the comparison would miss many records in the search.
>
>OK, but you still have to watch out for 0 length fields. What you could do is a PADR(TRIM(datafield),len_of_datafield) to make sure you don't get a 0 length value.
>
>
>>
>>Thanx
>
>You're welcome! Sorry I couldn't come up with an answer for the first part.

Fred,

Thanx anyhow, when I solve the mystery, I'll let you know