Thread

Whenever I to add or edit entries in one of my weblogs (ExpressionEngine 1.6.2 Build: 20080129). I receive the following message:

MySQL ERROR:

Error Number: 1054

Description: Unknown column 'field_id_17' in 'field list'

Query: UPDATE `exp_weblog_data` SET `weblog_id` = '5', `field_id_14` = '\"image\"', `field_ft_14` = 'none', `field_id_17` = 'a', `field_ft_17` = 'none', `field_id_15` = 'You have to decide whether you want Moot installed on your laptop only or to both laptop and your Windows mobile. To enjoy the full experience we recommend the latter, but if you choose to install on the laptop only you still are a Mooter.', `field_ft_15` = 'xhtml', `field_id_16` = 'Moot is installed like any other piece of software. Simply click the download button and follow the instructions. For now Moot runs on Windows XP, Windows Vista and Windows Mobile Phones with WLAN. But please check this website to look for updates and new supported platforms.\n', `field_ft_16` = 'xhtml', `field_id_26` = '', `field_ft_26` = 'none' WHERE entry_id = '16'

I read the forum post here and followed the advice as I recently added and deleted custom fields from a field group. I’ve repaired and optimized all tables via the SQL Manager. I don’t have any related fields that could be calling in anything I’ve removed nor do I have any extensions installed. Unfortunately I can’t upgrade to the latest version right now. When I view the exp_weblog_data table field_id_17 isn’t there. Does anyone have any advice as to what I could try next?

Thanks

Coincidentally, I just ran into the same problem. I added a custom field to a field group. It now gives me a 1054 error when I try to search entries within that group.

I optimized the tables. When I tried to delete the custom field, I get another error message:

MySQL ERROR:
Error Number: 1091
Description: Can’t DROP ‘field_id_54’; check that column/key exists
Query: ALTER TABLE exp_weblog_data DROP COLUMN field_id_54

The problem also appears to be causing problems for an SAEF in a completely different weblog.

FYI, I have no extensions to disable and my version is 1.6.2.

Are either of you using the MSM?  Fixing this shouldn’t be a killer- scottb has the right idea.  But we should figure out why the heck it happened in the first place.  Ever import data or manipulate the db manually?  And scottb- you’re dead sure you see that field when you look at the exp_weblog_data table?  No chance it’s field_ft_54?

Hi Robin,

No MSM on my site and no manual manipulation of the db either.

Interesting- field_id_17 actually has post content in that one.  OK- do a ‘reveal code’ on the publish page.  The search for ‘field_id_17’- about has to be there somewhere.  Copy paste the bit in the form related to it.

That make sense?

I’m not sure what MSM is, so I’m guessing I don’t use it. 😊

Interesting—there is no field_id_54 or field_ft_54 in exp_weblog_data.

I imported quite a bit of data using CSVgrab about a month ago. Everything was fine until I added that extra custom field late last week.

OK- do a ‘reveal code’ on the publish page.  The search for ‘field_id_17’- about has to be there somewhere.  Copy paste the bit in the form related to it.

Sorry Robin, forgive me - what do you mean ‘reveal code’?

Oops- sorry.  Just in your browser, right click and ‘view code’ or ‘view page source’- something like that.  We want a look at the generated html.  Then search for the field_id that’s missing so we can see where it is.  I’m guessing it’s actually the exp_weblog_fields table that’s off if you folks aren’t seeing the field in exp_weblog_data.

scottb- you could be off due to importing.  Jamie- any idea how yours could have gotten ‘off’?

...right click and ‘view code’...

Sorry..!

OK, here’s the source from my publish page:

Jamie- any idea how yours could have gotten ‘off’?

We have had a recent server move - but I added and removed custom fields only on the new server - would this be an issue?

Our host recently moved the database to another server as well. It happened a few weeks ago. I noticed problems at that point, and they said they made the fix. I contacted them yesterday about this new problem. They said they couldn’t find anything wrong. I added the new custom field after the move as well.

Hm- I wonder if auto_incrementing got off on one of the tables.  But I’d expect it to behave different.

OK- Jamie- it looks to me like field_id_17 is a valid and desired field- correct?  You want to keep it- problem is, there is no field_id_17 in exp_weblog_data- correct?

Scott- how about you- can you track yours down and does it appear to be a valid field- problem is, we just want to be able to enter data in it?

A couple of ways to see what it does- go to exp_weblog_fields- find the one with the id that generates the error.  In Jamie’s case- should be an id 17 in there.  Is it there- and does it match the instructions/name etc you see in the form?  (It should- that’s where it’s coming from.)  Scott- same deal, you’re just looking for id 54 in there.

I think both fields will be there.  I also think they will show in ‘Admin- Weblog Admin- Custom fields’.  All look ok so far.

Now- if those fields are there AND we want to keep them, we’ll need to add the fields to exp_weblog_data.  Don’t do it yet.  (And if we want to ditch them, should be able to drop them from exp_weblog_fields.)  Don’t do this yet, though.

And- since it looks like we’ll dink w/the db directly- make sure you make a good, current backup.  Then let me know what needs doing- keep the field (add to exp_weblog_data) or ditch it (drop it from exp_weblog_fields).  (And if this feels like baby steps and you know what to do now, proceed at your own risk.)

Once we get it fixed, might be a good idea to add a new field, make sure it works.  Since both installs have been moved a bit, I’m hoping things got off there and not with the EE code itself.

Yes, you are correct, 54 exists in weblog_fields and in Custom Weblog Fields but not in weblog_data.

I want to delete it altogether from the database.

Yes, you are correct, 17 exists in weblog_fields and in Custom Weblog Fields but not in weblog_data.

I want to keep it in the database.

OK- scott only- to get rid of it, be sure to back up first- then run

DELETE FROM exp_weblog_fields WHERE field_id = 54

Also- double check that exp_weblog_data doesn’t have a field_ft_54.  Don’t think it does, but double check.

Again- be sure you have a good backup.  And then I’d probably create a new field, publish to test- then go in and delete it.  Publish to test.  In other words- make sure it’s working like it should be.  We want to be sure the source of the problem is gone.  I’m hoping it was just something goofed up in transfer and the problem can’t be replicated once we’ve got the db tables synced again.  Also- might go ahead and optimize tables while you’re mucking w/the db.

Make sense?

Makes sense, thanks. I don’t have the ability to do a backup, only my vendor does. I’m waiting for them to take that step and will let you know the result.

Also, just to make sure, I assume the sql command is done within Database Query Form. Please let me know if that’s not the case.