Re: text type handling

OK, this is the exactly the data we need. So neither Daniel's nor my
solution are completely adequate. It seems what we need is an option to
specify the precision value returned for unknown length items. That
will allow you to set it to whatever value you want.

Daniel, do you have a specific case where LONGVARCHAR is needed instead
of being able to set the precision?

Kris Jurka

Ken Boss wrote:
> OK, bear with me here - I don't have access to Crystal's internals, I
> can only report empirical observations...
>
> The Crystal report designer has a feature they call the Field
> Explorer that lets you browse the fields in the tables that are
> accessible to the report, and displays what Crystal considers to be
> the field type for each.
>
> Using an unmodified 8.4dev-700 driver, both pg text and
> varchar(unlimited) types show up in the Field Explorer as types
> String[-1], and simply fail to display in the report.
>
> After applying Kris's patch (plus one more line for the Oid.TEXT
> case), the situation remains the same. As suggested, presumably
> values approaching Integer.MAX_VALUE push things into an overflow
> situation, so Crystal reverts to the String[-1] representation.
>
> Substituting an integer < 65535 in place of Integer.MAX_VALUE in the
> patch causes pg text/varchar(unlimited) fields to show up in Crystal
> as String fields of the specified length, which will then display in
> the report.
>
> Substituting an integer > 65535 but less than Integer.MAX_VALUE (eg.,
> 1000000) yields String[65534] for those pg types, and they continue
> to display in the report (presumably up to 65334 chars, anyway).
>
> Daniel's patch (which hasn't addressed varchar(unlimited)), OTOH,
> causes pg text fields to appear in the Field Explorer as type Memo
> (which is what Crystal produces from Oracle CLOBs). Memo fields are
> marginally easier to display in a report (they auto-wrap until their
> contents are fully output, where that has to be arranged in a
> separate step for long String fields), but are constrained primarily
> to display purposes, and cannot be used in Crystal formulas, as
> variables, etc., so IMHO might be a slightly less desirable option
> than long strings.
>
> Clearly you don't want to be designing your drivers to conform to
> some commercial software package's usage, but if there's a
> reasonable, spec-conforming solution that would work in light of the
> above, I for one would be grateful to see it implemented.
>
> Thanks,
>
> --Ken
>
>
>>>> Kris Jurka <books(at)ejurka(dot)com> 12/03/08 1:53 PM >>>
>
>
> On Wed, 3 Dec 2008, Ken Boss wrote:
>
>> Thanks much for your response, Kris. I have been able to make
>> things work for my purposes by applying the patch suggested by
>> Daniel Migowski in the thread referenced below. I tried to
>> implement your suggestion as well, but know only enough to be
>> dangerous. Returning Integer.MAX_VALUE from the Oid..TEXT case in
>> the getPrecision method of TypeInfoCache.java had no discernible
>> effect - I must have been coding in the wrong place. At any rate, I
>> will look forward to that fix in the next release.
>>
>
> That's basically what I had in mind, but for a couple more types as
> well (see the attached patch). If this doesn't work we need to know
> that so we can come up with something else, so your testing is
> appreciated. Can you be more clear about what Crystal Reports does
> when it gets confused? Is it possible that CR is trying to calculate
> a total row size in an integer value and overflows when it sees
> Integer.MAX_VALUE? If so, returning some other large, but not huge
> value might work.
>
> Kris Jurka