Re: [INTERFACES] varchar() access

Byron Nikolaidis <byronn(at)insightdist(dot)com> wrote:

> Mark Himsley wrote:
>
> > No one has any comment at all?
> > Not even 'your a dick-head'!
>
> Oops, since I didn't see ODBC in the subject, I missed it. But hard to miss that line!

Sorry, I'll put ODBC in the subject next time.
I feel suitably chastised <grin>

> > > I'm accessing a postgres 6.3 server on Linux 2.0.35 using the 6.40.0004 ODBC driver on NT 4S.
> > >
> > > I am having a problem with varchar columns being truncated to 4K bytes when coming from the backend, although I can store > 4K into the backend.
> > >
> > > I have set max LongVarChar to 7000 and -4 (as suggested in the FAQ)
> > > I have tried checking and not checking the 'text as LongVarChar' box.
> >
>
> Yes indeed, the driver has an internal limit of 4k on text fields *plus* Postgres has a limit of 4k too. The ability to set the number was more
> intended for applications that needed it to be lower. Like Access will allow you to index on a text field if you set this number to 254.

I thought Postgres had a limit of 8K? That's what it says in the docs...

Anyway, as I said I can put more that 4K worth of data into a text field
via ODBC, and I car get all that data out using a SELECT in the psql
command line interface. It's just a bit frustrating that I can't get
this data out when accessing the same database via ODBC.

> We have run into this problem before of the 4k limit. You could try using large objects, but I'm not too sure how they will work with character data,
> as they were more intended for handling LongVarBinary data. If you are going to create a column in the table yourself to hold this long char data,
> you should probably check the faq which describes how to setup a "lo" data type. That is the only way the driver will recognize it as a large object.

Thanks. I think I'll actually try a different approach, being that I'll
split the data into 4K chunks and store it into separate sequenced
records. This will only work with a program writing the data rather than
appending the data with Access.

This is something I can do quickly, to get the web site I promised would
be live last Wednesday.

--
Mark Himsley.
Technical Director,
Clockwork Web.