Importing Data

[CEC]

I'm finding importing categories and links very hit and miss -- using IndexU there is no explanation of possible errors; categories just don't show up if there's something wrong. Today was a miss, so I tried to importing directly using phpmyadmin. The following error was received:

#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '6606 109526 Ashland ... (the first row)

It's very strange. The structure and format is identical to successfully uploaded files.

Any feedback is appreciated.

[ezykiwi]

Howdy CEC

Ive only ever used phpmyadmin to upload data of categories etc, and havent had any problems...

What kinda of file are you uploading? I normally just used a text file (tab delimited)

Cheers Ezy

[CEC]

Howdy back at, ezykiwi!

I always use a tab delimited .txt files. The structure of those not importing is identical with the majority that work.

It's frustrating -- in part because '#1064 - You have an error in your SQL syntax ...' is an error that if you search in Google is all over the place. Yet there doesn't seem to be a clear-cut way of dealing with it.

[inspireme]

an error in your sql syntax is just that... phpmyadmin doesnt know how to handle it. You probably have the ' character in your field data.

[CEC]

an error in your sql syntax is just that... phpmyadmin doesnt know how to handle it. You probably have the ' character in your field data.

No '

The same structure and syntax for those that are working, and those that aren't -- each are the output of the same merge document, which forces conformity.

[ezykiwi]

What i normally do when i get a error like that, is I do a test by trying to insert 1 field via the text file, that way you can find out if its the file structure or if like inspireme said its data in the fields....

also how big is the text file?

Cheers Ezy

[esm]

No '

The same structure and syntax for those that are working, and those that aren't -- each are the output of the same merge document, which forces conformity.

well, something is NOT conforming. if the data was correct, then it would be accepted. Since it is not accepting the data, then the data is not correct.

You say the data is the same. But if it were the same, then it would be accepted. ERGO: the data is not the same.

Computer software is nothing if not repetitious. It doesn't do one thing today and something different tomorrow. It doesn't work one way on one computer and another way on a different computer.

I don't know why folks don't learn this . They want to challenge this and suspend the laws of how things work to explain the errors they see.

Everything else being the same, if it says you have a syntax error, then trust me, you have a syntax error . Well, you may have been the one on one billion that finds a bug, but don't hold your breath.

after all is said and done, you still have a syntax error. Find out what is causing the syntax error. You can tell us all day about how you do this or how you do that. but that is mostly irrelevant.

when it says you have a "syntax [error] ... near '6606 109526 Ashland" then trust me, you have a syntax error with that part of the SQL code.

Remember you are using PHP (which has its own syntax) to create a SQL statement (and SQL has its own syntax). Properly merging the two syntax's is where almost all of my problems occur.

check to see if you have the right number of quote marks and that they are in the right place. Single and double. Check for commas.

try posting the exact sql statement. or the line you are importing.




.

[CEC]

Remember you are using PHP (which has its own syntax) to create a SQL statement (and SQL has its own syntax). Properly merging the two syntax's is where almost all of my problems occur.

Thanks ESM.

This is likely at the root. As noted, I have only been able to successfully import through IndexU -- which is fine -- I don't care how it gets in there. But, again, it's just not accepting about 1 in 4.

The full error message in terms of my attempt at using phpmyadmin is in my first post.

Thanks for bearing with me.

[esm]

how many fields are do you have?



.

[CEC]

There are 20 fields.
c

[esm]

i can't check for tabs in what you posted, but that is another thing to look for: the correct number of fields/tabs in your imported lines.

Yep, I know that you processed the data so that it would be the same but it isn't. you have a syntax error somewhere.



.

[CEC]

Here's the unsuccessful during IndexU import (delimiting shows). I do notice 'orderr_num' does not correspond to 'order_num' in SQL -- not sure how to account for this discrepancy or its affect on things?? -- especially considering many successful imports.

[esm]

Here's the unsuccessful during IndexU import (delimiting shows). I do notice 'orderr_num' does not correspond to 'order_num' in SQL -- not sure how to account for this discrepancy or its affect on things?? -- especially considering many successful imports.

i don't know about your other imports but you will get a syntax error (sound familiar...?) if you have an incorrect column name (like 'orderr_num')



.

[CEC]

Do you happen to know where to find this field to correct it in IndexU? I have only used its default settings for these fields -- I don't even use this field.

Still get the error when using phpmyadmin. Sorry, but the beginning of the error looks like this:

ERROR: Unknown Punctuation String @ 48
STR: </
SQL: 6520109525 Andover

The first line start with SQL: 6520109525 category and parent id have no space. All of the other records are spaced properly.

[esm]

the actual field name is order_num

the _511.sql file in the install folder shows the field names that were used during the creation process

You would ALWAYS get a SQL error if you used the column name 'orderr_num' if the actual column name is 'order_num.'

And how often is ALWAYS? ALWAYS. and that does not mean every fourth or fifth one, or 4 out of 5.


.