Problem importing CSV file into Table (1 Viewer)

[Lateral]

Everything has been working fine for a very long time.

And what is the data type of the Yes/No fields when you import the file without a spec? Are they STILL Y/N???? Please go back and read #10 again. I can't see your file.

Also, you can link the spreadsheet. Then view it and sort on the new Y/N column. First ascending and then descending. Does EVERY row have a value?
This is like pulling teeth.

Hi Pat

As I said it #19, without a Specification defined and outputting to a new table, ALL of the fields in the new table are defined as TEXT.

If I then rerun the Import without a Specification and point the output to the existing Web_Parts table, ALL of the data is imported without any errors.

 

[arnelgp]

here is a A2007 version.

 

[Pat Hartman]

If all the fields are defined as text, that tells you that there is INVALID data in the file. If the data were valid, the data types would be numeric where appropriate. Your join date is 2013. You should, by this time, have some concept of debugging.

 

[arnelgp]

read back to see the structure.

 

[Lateral]

If all the fields are defined as text, that tells you that there is INVALID data in the file. If the data were valid, the data types would be numeric where appropriate. Your join date is 2013. You should, by this time, have some concept of debugging.

Hi Pat,

Thanks for the sarcastic and disappointing comments.

Perhaps you need to read my replies a bit better as I have been providing detailed information that you seem to be having trouble interpreting.

Thanks everybody for trying to help me but I'm signing off and will find a solution elsewhere....

Cheers
Greg

 

[ebs17]

You ignored that - because you want to keep your problem?

DoCmd.TransferText acLinkDelim, "ImportWebParts", "Web_Parts", "C:\testmiport.csv", True, ""

Link the CSV. This allows you to see what content is actually being delivered. Using a recordset on it, you can check the resulting data types of the fields (Field.Type). You can use an append query to test how the data is accepted by the target table and perhaps draw new conclusions from it.
As part of the query, you could make any necessary additional reformatting.

I think your import specification is not quite right and you need to correct it. TransferText is access to the text file (text table) via Jet/SQL. It must be defined how this text table is to be read in order to be able to use it subsequently. If no explicit import specification (alternatively Schema.ini) is used, Jet access takes standard information from the registry. However, if standard information from the registry works better than your specification, you should think and test.

I have been providing detailed information

Stories and pictures.
Helpful details would have been:
- A csv with a few lines, but which also contains problematic content
- An own DB file with the table and the import specification used.
That would give you all the facts you would need for a real judgement.