Re: Carriage return in text fields

From: Ian Harding <harding(dot)ian(at)gmail(dot)com>
To: Ets ROLLAND <ets(at)rolland-fr(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Carriage return in text fields
Date: 2005-05-31 04:30:07
Message-ID: 72560230050530213048de8bbc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In my experience, there is no way to tell an embedded carriage return
from and end-of-record carriage return other than counting intervening
tabs.

What I do, is fix it in access with a query for (believe it or not)

"*" & chr(13) & "*"

which returns all records that contain a CR. I then just delete the
extraneous CR before exporting the data.

If access could use a different record delimiter on export life would
be good, but it doesn't.

You could also run a script on your exported data that would count
TABs on a line before the CR/LF was encountered, and delete any that
appear too early. I am not smart enough to do that.

Good luck.

Ian
On 5/30/05, Ets ROLLAND <ets(at)rolland-fr(dot)com> wrote:
>
> Hello !
>
> I have to transfert data from MS-Access to PostgreSQL 8.03 under Windows
> 2003 server.
> Text fields may contain a carriage return (CR-LF).
> I use the copy instruction.
> Under Pg-Admin III 1.21, I obtain an error message for that carriage return
> and a hint : use \n.
> If I use a filter on the cvs file replacing carriage return with \n, copy
> works but I have the char \n
> in the text fields, not the carriage return !?
> If I use PSQL, the carriage return are replaced by a space !
> In Pg-Admin III I can insert a carriage return (with SHIFT ENTER) in a text
> field.
>
> How can I transfert my text fields WITH all the carriage return inside the
> text fields ?
> Thanks for your tips...
> Best regards.
>
> Luc

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-05-31 05:03:30 Re: CREATE TEMP TABLE AS SELECT/ GET DIAGNOSTICS ROW_COUNT
Previous Message Bruce Momjian 2005-05-31 04:22:53 Re: numeric precision when raising one numeric to another.