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