>>Thanks,
>>I'll do that.
>>Its curious to me that the driver info is set into the report and changing it requires hacking the report. Why isn't there an option setting in the report designer? You'd think it's pretty important.
>
>I tend to agree, but I also realize that to some extent we're paying the price for maintaining some degree of backwards compatibility and for relying so strongly on the built-in tools. The FRX hasn't changed a great deal since FP 2.x, and retaining the behavior from earlier versions has some cost; there has been considerable furor when new versions of VFP dropped support for things with roots back in the time before MS.
>
>Fortunately, others figured it out and let us know about it.
>
>I also take the shortcomings of the Report Writer in stride. No (sane) VB programmer relies on the native VB report too; perhaps because VB people are used to the idea of adding the right widgets when they need greater capability. We have much the same options; there are several strong report products that are able to support VFP well, or are entirely geared to the VFP environment.
>
>I'm more inclined to buy what I need rather than try to make the native stuff behave in ways it doesn't like. It's usually cheaper to buy a better tool than spend lots of time kludging. The more ornate and baroque the kludge, the more likely it will fall apart and make me start all over...

Well said. I'll be looking into a report writing product. But I would liken this situation to a bug in the Report Designer. I understand backward compatibility needs, but then I think MS can at least document this. It's the community VFP has to help get thru these kind of problems, that clearly makes VFP such a strong development tool. VB'ers are solving their problems with new (non MS) tools which work better. We can get our solutions thru the community we keep. Viva la VFP. Thanks again.