Re: insert aborted commands ignored
| От | Pepe TD Vo |
|---|---|
| Тема | Re: insert aborted commands ignored |
| Дата | |
| Msg-id | 979487675.4817021.1549568623947@mail.yahoo.com обсуждение исходный текст |
| Ответ на | Re: insert aborted commands ignored (Pepe TD Vo <pepevo@yahoo.com>) |
| Список | pgsql-admin |
Mr. Johnston,
for the error, "value too long for type character varying(34)thank you for your information. I resolved the problem.
v.r,
Bach-Nga
No one in this world is pure and perfect. If you avoid people for their mistakes you will be alone. So judge less, love and forgive more.
To call him a dog hardly seems to do him justice though in as much as he had four legs, a tail, and barked, I admit he was, to all outward appearances. But to those who knew him well, he was a perfect gentleman (Hermione Gingold)
**Live simply **Love generously **Care deeply **Speak kindly.
*** Genuinely rich *** Faithful talent *** Sharing success
On Wednesday, February 6, 2019 2:59 PM, Pepe TD Vo <pepevo@yahoo.com> wrote:
Thank you sir,
I have tried one by one to show create table back and found a few fields with character varying(34) and I don't know exactly which one failed. The data type was right from Oracle and count the characters on the insert script was fine. The target column names listed in order but the values supplied by the values are associated with the explicit or implicit column list left to right and I need to check one by one column and see what they are. The problems are so many and the more I query, psql hung and I needed to ctrl C to get out from psql and get back in.
I am checking one by one table insert row now. I need to pull all insert of each table out first and see if insert ok and so far it's ok. With your information I will check back and increase the values (n) and see the insert work or not, since the insert script was 20Gb and it will stop running as soon as the error kick in. Even without setting "-v ON_ERROR_STOP=1 ". The 1st 200 insert lines are ok from the psql prompt but stop insert if I running psql -U postgres -d CIDR < insert_cidrdba.sql > insert_cidrdba.txt. I am inserting one by one from psql now. Hope to find where the error occurs.
thank you for your input again.
v/r,
Bach-Nga
No one in this world is pure and perfect. If you avoid people for their mistakes you will be alone. So judge less, love and forgive more.
No one in this world is pure and perfect. If you avoid people for their mistakes you will be alone. So judge less, love and forgive more.
To call him a dog hardly seems to do him justice though in as much as he had four legs, a tail, and barked, I admit he was, to all outward appearances. But to those who knew him well, he was a perfect gentleman (Hermione Gingold)
**Live simply **Love generously **Care deeply **Speak kindly.
*** Genuinely rich *** Faithful talent *** Sharing success
On Wednesday, February 6, 2019 10:18 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Wed, Feb 6, 2019 at 8:05 AM Pepe TD Vo <pepevo@yahoo.com> wrote:
> get another error, "value too long for type character varying(34). How do I know which table
How many tables in your schema are defined with a column having a type
of "character varying(34)"?
To narrow down if >1 you'd need to trace the load script and see at
what point it is failing; or change half of them to "text", try again,
change some back to varchar(34), try again repeat until only one of
them is "text" and that is your culprit.
Or just get rid of "varchar(n)" columns, make them all text and, for
those were you really want to keep length limits, add explicit
constraints.
There have been discussions somewhat recently to make the error
message itself more helpful but I don't believe anyone is actively
working on it. Its better, IMO, to avoid using "varchar(n)" in your
schema anyway. More precise check constraints are a better option not
the least of which is because they can be named and self-identify with
the table to which they are attached.
David J.
> get another error, "value too long for type character varying(34). How do I know which table
How many tables in your schema are defined with a column having a type
of "character varying(34)"?
To narrow down if >1 you'd need to trace the load script and see at
what point it is failing; or change half of them to "text", try again,
change some back to varchar(34), try again repeat until only one of
them is "text" and that is your culprit.
Or just get rid of "varchar(n)" columns, make them all text and, for
those were you really want to keep length limits, add explicit
constraints.
There have been discussions somewhat recently to make the error
message itself more helpful but I don't believe anyone is actively
working on it. Its better, IMO, to avoid using "varchar(n)" in your
schema anyway. More precise check constraints are a better option not
the least of which is because they can be named and self-identify with
the table to which they are attached.
David J.
В списке pgsql-admin по дате отправления:
Предыдущее
От: "Bawol, Brian"Дата:
Сообщение: Re: PgAdmin 4.2 unable to connect to AWS Postgres read-replica instances
Следующее
От: Alvaro HerreraДата:
Сообщение: Re: PgAdmin 4.2 unable to connect to AWS Postgres read-replicainstances