Hello Gregory,
Gregory Stark schrieb:
> "Daniel Migowski" <dmigowski@ikoffice.de> writes:
>
>
>> I can understand your concerns, if you are used to applications that store
>> everything in text-fields on the database. But a problem is only if you have
>> such an applicatoin, and forgets about its database fields and uses the
>> metadata to remember what its fields have been, now notices the data is in
>> LONGVARCHARs, and uses the stream-methods.
>>
>
> I think that's quite likely though if you build an application and then later
> throw some generic tool at it such as a reporting tool, or a schema design
> tool, or a migration tool or something like that.
>
Is reasonable, yes.
> But I wouldn't be too worried about a slowdown. I would be more worried about
> having said tool see LONGVARCHAR and throw its hands in the air and refuse to
> include it in your reports. Or insist on migrating it to or from MEMO fields
> instead of plain strings.
>
What would be the problem with this? text fields ARE memo fields. Use
varchar(n) if you want length constrained fields :).
> Perhaps this is all just FUD though.
In fact LONGVARCHAR is made easy in JDBC, since it is required to be
accessible by the same functions as VARCHAR.
> I haven't seen such a case myself. I was
> under the impression such cases had been previously posted on list but if
> you've searched and not found anything then perhaps I'm thinking of some other
> scenario.
>
In fact I searched for LONGVARCHAR on the list, and everything I got are
complaints that it is not supported in the metadata (in about 4
threads). Of course we could not get complaints for the reversed case,
in which LONGVARCHAR itself was a problem, yet.
With best regards,
Daniel Migowski