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

On Wed, 3 Dec 2008, Kris Jurka wrote:

> 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.

I have added a new URL parameter, unknownLength, to allow the user to
specify the desired return value for types of unknown length.

Kris Jurka

Hi,

Sorry for digging up an old post but I'm facing the descibed problem and
have some wondering about.
I'm using Crytal Report whith postgresql via the driver jdbc4 9 0 801.
The text columns are shown in CR as String of length -1 (hence producing
hazardous character in report)

I've read the discussion but could not understand if any correction has been
implemented or not. (discussion dates from 8.3 or 8.4)
I don't see how to deal with the above mentioned parameter unknownLength.
Can I access it and set it myself?

Thanks for your time
Marc
--
View this message in context: http://postgresql.1045698.n5.nabble.com/text-type-handling-tp2175473p3331613.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

> I've read the discussion but could not understand if any correction has been
> implemented or not. (discussion dates from 8.3 or 8.4)
> I don't see how to deal with the above mentioned parameter unknownLength.
> Can I access it and set it myself?

Yes, this is a jdbc URL parameter as of 8.4 (?)--e.g.,
jdbc:postgresql://localhost/postgres?unknownLength=500 . See
http://jdbc.postgresql.org/documentation/84/connect.html .
---
Maciek Sakrejda | System Architect | Truviso

1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com