Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] varchar() access

From: Byron Nikolaidis <byronn(at)insightdist(dot)com>
To: markh(at)clockworkweb(dot)com
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] varchar() access
Date: 1999-01-28 18:51:28
Message-ID: 36B0B1B0.3C13B9D3@insightdist.com (view raw or flat)
Thread:
Lists: pgsql-interfaces

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!


> Oh well, I guess I'll have to re-write my code to cope with this problem
> that I am having.
>
> > 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.

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.

Currently, the driver can only "retrieve" the character data from a large object (if this whole thing works), such as in a BindCol or GetData call..
There is no way it would be able to send LongVarChar data to a large object, such as in a BindParameter or data-at-execution parameter.  It is
currently only capable of doing this for LongVarBinary data type.

So if you have control over what kind of field you are binding, then you *should* be able to use longvarbinary, and it possibly will work.

The real solution is to allow an option in the driver of mapping a large object to a LongVarChar data type, instead of a text field.

Let me know what happens.  Maybe if you hound me on this issue, I may add it.

Anybody else have any feelings on the LongVarChar-->Large Object issue?

Byron




In response to

Responses

pgsql-interfaces by date

Next:From: Michael MeskesDate: 1999-01-28 18:58:59
Subject: Re: [INTERFACES] Use ecpg
Previous:From: Brian SchneiderDate: 1999-01-28 18:22:05
Subject: unsubscribe

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group