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

The following bug has been logged on the website:

Bug reference:      17498
Logged by:          Jam Paydaovusi
Email address:      jampaydavousi@yahoo.com
PostgreSQL version: 11.4
Operating system:   Mac OS 10.15.7 (Catalina)
Description:

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

This used to work for years since 2019, and now it is not working anymore.

Checked the csv files for column syntax and values types and cross
referenced against column names and value types.  Find no issues.  

Cannot find any step by step trouble shooting steps or tips when I do google
search.   

I cannot find any import logs from the previous successful csv imports to
see why those were successful and the the current imports - regardless of
which directory the csv files reside in do not work.


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