This has become intractable ...
I'm trying to import Links 2.0 tables (links.db and categories.db).

The categories go in OK, no problem.

The links refuse. The reason seems to be that I don't have columns
for Rating or Votes. They are features which not relevant to our project, so I removed them from the default links table.

Here is a line from the error message

Code:

Import error: WARNING: Unable to insert link `owner'
(SQL query: `INSERT INTO art_Links (ID, LinkOwner, isValidated, Add_Date, Mod_Date,
Contact_Name, Contact_Email, Title, URL, Description, Hits, isNew, isPopular,
Rating, Votes, <My_New_Columns>)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'):
Unknown column 'Rating' in 'field list'

I get a line like that for every link!

<My_New_Columns> represents the whole set of non-standard columns in the Links 2.0 file.

It seems to be demanding Rating and Votes even though they are
not in the Links SQL table, and they are not defined in the table to
be imported.

Is this a bug? Or am I doing something wrong?

Are these columns hard-wired?
If they are, how can I remove them?

Do you have the tick box for creating non-existant columns selected?

I've had this problem once before doing a large DMOZ import for someone and got around it by creating the columns manually.

Yes, it was selected. I thought it meant that Links SQL should create columns to match those it found in the def files -- that is exactly what it did for the categories.

There was no reason for Links SQL to re-create Ratings and Votes. They are not in links_Links.def.

I think it's a BUG. I just found this in ConfigData.pm ...

Code:

'add_system_fields' => {
'isChanged' => 'No',
'Rating' => '0',
'Hits' => '0',
'Votes' => '0',
'isPopular' => 'No',
'isNew' => 'No',
'Status' => '0'
}

So it may be caused by Ratings and Votes being defined as 'system fields', even though they do not exist. We also want to remove Hits and isPopular, as they have no useful purpose -- we won't be using jump.cgi

Did you remove those from your working site?

If so, during an import, they are re-added, since they are some of the default Links fields. It's _NOT_ a good idea to remove any of the default fields, just ignore them. The only place they will keep coming up anyway is in the Admin area.

I think your error is that the "required" columns are missing.

The problem may be a tad more complex than that, with the .def files out of sync with the database that is being imported, or being imported to. Sometimes it's the .def file that is the problem, not the database. But.... your .def files _really_ need to match your database when you are doing any database altering work -- so it's a good idea to resync them just in case.

.def files are used to hold extra field information Links uses, as well as improve performance by allowing array acess to fields that are used as hashes, and such. The problem is, that if they get out of sync, all your access will be "off" and you can really screw up your database!

Try to figure out what is happening with each database.

1st do the .def files match the databases they represent
2) do the databases have all the required fields for input
3) do the fields all match up -- if not, do you have the 'create missing fields' box checked (this only creates fields for IMPORT.... ie: fields missing from the imported file. It won't replace fields missing _IN_ the database being imported into)

Hope this helps give you something to work with.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hi,

Pugdog is right. Don't remove any system fields. The import has some system fields hard coded in it and may not work correctly if you have removed default fields.

Cheers,

Alex
--
Gossamer Threads Inc.

OK. I can confirm that removal of 'system fields' generates side effects. I had several other problems afterwards, eg: new columns not showing up.

What I don't understand is why 'Ratings' and 'Votes' should be system fields in the first place. System fields should be those which are essential to the functioning of the database.

I'm relieved that we don't have to use these two. They are non-essential default columns. The database should not depend on their existence in the table.