BUG #17498: Receive Failed: (error code 1) when importing any csv file from pgAdmin with no explanations

PG Bug reporting form <noreply@postgresql.org> writes:

Receive Failed: error code 1) when importing any csv file from pgAdmin with
no explanations in the 'Details' section

It seems likely that that is a pgAdmin problem, not a problem in
core Postgres, in which case this is the wrong place to report it.
See https://www.pgadmin.org/support/issues/ instead.

If you can reproduce a similarly uninformative failure without
using pgAdmin -- say, by using COPY in psql -- then it'd be
appropriate for this list to look closer.

regards, tom lane

Never mind I solved the problem. I had to replace 'INT' with 'BIGINT'  forgot 10 digit mobile numbers require 8 bytes.
I will go and close the ticket.  

Jam
On Wednesday, May 25, 2022, 02:20:33 PM PDT, jam paydavousi <jampaydavousi@yahoo.com> wrote:

Thank you for following up Tom.  I did what you instructed- i.e., filing distinctly from pgAdmin link you provided.
However, I have the same issue when I attempt to import the csv file via the command line interface on mac terminal. It copies 0 rows

postgres-# \copy alove from '/Users/jam/alovel.csv' delimiter ',' csv header;

COPY 0
postgres-#
I am able to see the same databases that I see in pgAdmin by running ... psql \l ...from the command line.  So I am not sure what troubleshooting I need to do.  The csv file that I am trying to import is a small csv file with 80 rows of 10 digit mobile numbers.  And on the SQL side, I created a table with one column with the same header 'Mobile' with values of type INT.
Any suggestions on troubleshooting from command line interface side?
Thank you
Jam Paydavousi 
On Wednesday, May 25, 2022, 01:06:14 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

Receive Failed: error code 1) when importing any csv file from pgAdmin with
no explanations in the 'Details' section

It seems likely that that is a pgAdmin problem, not a problem in
core Postgres, in which case this is the wrong place to report it.
See https://www.pgadmin.org/support/issues/ instead.

If you can reproduce a similarly uninformative failure without
using pgAdmin -- say, by using COPY in psql -- then it'd be
appropriate for this list to look closer.

            regards, tom lane

jam paydavousi <jampaydavousi@yahoo.com> writes:

Thank you for following up Tom.  I did what you instructed- i.e., filing distinctly from pgAdmin link you provided.
However, I have the same issue when I attempt to import the csv file via the command line interface on mac terminal. It copies 0 rows

postgres-# \copy alove from '/Users/jam/alovel.csv' delimiter ',' csv header;

COPY 0

Hm. Sure looks like Postgres thinks the file is empty.

That "CSV HEADER" option would silently eat the first line, so I'm
wondering if the data looks like it's a single line to COPY,
ie maybe there is something funny about the newlines in your file.
You could check this theory easily by leaving off "CSV HEADER"
and seeing if the results change.

regards, tom lane

Hi Tom,
It is odd that there was no description in the Failed error code:1 in pgAdmin, suggesting mismatch between how the column needs to be defined so SQl can import it.  The psql error description  on command line on Mac terminal was detailed, to the point, and helpful in troubleshooting it.  
Thanks for your timely reply and help in troubleshooting.  My PostgreSQL tables are loading all CSV files now, my python code in Flask is reading and converting data from SQL using SQLAlchemy with no errors, and my front end is showing the data. All si good now.  
Best Regards to you.
Jam
On Wednesday, May 25, 2022, 02:57:21 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:

jam paydavousi <jampaydavousi@yahoo.com> writes:

  Thank you for following up Tom.  I did what you instructed- i.e., filing distinctly from pgAdmin link you provided.
However, I have the same issue when I attempt to import the csv file via the command line interface on mac terminal. It copies 0 rows

postgres-# \copy alove from '/Users/jam/alovel.csv' delimiter ',' csv header;

COPY 0

Hm.  Sure looks like Postgres thinks the file is empty.

That "CSV HEADER" option would silently eat the first line, so I'm
wondering if the data looks like it's a single line to COPY,
ie maybe there is something funny about the newlines in your file.
You could check this theory easily by leaving off "CSV HEADER"
and seeing if the results change.

            regards, tom lane

On Wed, May 25, 2022 at 3:04 PM jam paydavousi <jampaydavousi@yahoo.com>
wrote:

Never mind I solved the problem. I had to replace 'INT' with 'BIGINT'
forgot 10 digit mobile numbers require 8 bytes.

IMO, and that of most modellers I suspect, the use of a numeric type to
represent a non-numeric phone number is the problem. While phone numbers
typically consist of digits they are not numbers - they are identifiers.
In particular, it makes no sense to perform math operations on them. I'd
suggest you use "text" for the data type - add a check constraint if you
want to ensure the imported data meets specific criteria.

David J.

Great point!  Thanks again
Jam
On Wednesday, May 25, 2022, 03:15:09 PM PDT, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Wed, May 25, 2022 at 3:04 PM jam paydavousi <jampaydavousi@yahoo.com> wrote:

Never mind I solved the problem. I had to replace 'INT' with 'BIGINT'  forgot 10 digit mobile numbers require 8 bytes.

IMO, and that of most modellers I suspect, the use of a numeric type to represent a non-numeric phone number is the problem.  While phone numbers typically consist of digits they are not numbers - they are identifiers.  In particular, it makes no sense to perform math operations on them.  I'd suggest you use "text" for the data type - add a check constraint if you want to ensure the imported data meets specific criteria.
David J.