When opening the account settings this error is shown:

user warning: Unknown column 'is_primary' in 'order clause' query: SELECT * FROM addresses_user WHERE eid = 1 ORDER BY is_primary DESC in /home/prosthet/public_html/modules/addresses/addresses_user/addresses_user.inc on line 40.

All modules are current - though most are not dev modules. Ubercart and Affiiates2 is installed and activated

Comments

AlexisWilke’s picture

AlexisWilke CreditAttribution: AlexisWilke commented

I suggest you use 1.x-dev since 2.x-dev is not being supported much. This problem was fixed in 1.x-dev.

Thank you.
Alexis Wilke

bobburns’s picture

bobburns CreditAttribution: bobburns commented

Thanks for the reply - I had already tried that. When I do, I get/got what appears to be a "hard coding error" as this:

Fatal error: require_once() [function.require]: Failed opening required 'modules/addresses/addresses.admin.inc' (include_path='modules/import_html/coders_php_library:.:/usr/lib/php:/usr/local/lib/php') in /home/xxxxxxxx/public_html/includes/menu.inc on line 346 (in the browser) . . .

when I try to navigate to /admin/settings/addresses . . . UNLESS I18n is installed as the latest dev version ONLY

(it is posted in another bug report I cannot find right now)

I have Addresses-Extra installed and no additional fields show - UNLESS I18n is installed and enabled and then it comes up as another "Address" box in the node stuck on the country "Zambia" - no other countries are available. Without I18n - an address box shows up - empty - no fields at all.

Then the error shows in Drupal's admin nodes as this:

warning: require_once(modules/addresses/addresses.admin.inc) [function.require-once]: failed to open stream: No such file or directory in /home/xxxxxxx/public_html/includes/menu.inc on line 346.

I do not think it shows up on the public side of the site.

I have the coders_php_library and those are the paths to php on my system I believe.

Enabling I18n freezes cron at believing it had not run for 15 weeks, and then I have to free the semaphores to get it to run after I remove I18n.

If I install the latest I18n dev module, the Addresses-Extra THEN comes up, and will allow the countries to be edited (all added or deleted - Zambia was the only country enabled initially) in /admin/settings/addresses - but the Status Report STILL reports cron not having run for 15 weeks 1 day - even though in Drupal Tweaks I can run it from the browser as http://xxxx.com/cron.php and Drupal Tweaks recognizes it as having run successfully - and I can clear the semaphores and it will show up in the Status Report as a info window [cron semaphores cleared], but the Status Report page node still will report cron run failed - and especially if cron is tried to be run manually from the Status Report node.

The Status Report node page still is reporting cron has not run for 15 weeks 1 day currently. This evil I will let sit for a while - as I need the rest of what I18n allows to be done in Drupal and I need to edit the address-extra fields for my purposes. I am running poormanscron as a triggered auto-cron - so I will wait to see if it still works - as reported possibly by Drupal Tweaks.

So right now - neither one works right - at least not without I18n-dev installed - which then causes the cron problem at the Status Report node-page

So I am running right now Addresses 1x-dev (2010-Dec-15) and Addresses-extra 1x-dev (2010-Aug-04) and I18n-dev (2010-Oct-14) - all the latest versions at this writing, and this is the only way Addresses Extra will work.

I am curious - does the Addresses 2.x dev version make irreparable changes to the database tables?

So any clues on what is going on here? Certainly it is a bug - maybe several.

AlexisWilke’s picture

AlexisWilke CreditAttribution: AlexisWilke commented

Ah... Maybe you tried to install 1.x over 2.x. You probably want to remove the folder completely and then extract 1.x back in there first.

And you may have some problems with the menus that can be cleared with the Rebuild menu option of the mini module (I think there is the same feature in the admin menu, but I don't know the exact name.)

So...

1. Delete the addresses and addresses_extras folders

2. Extract addresses version 1.x-dev and addresses_extra 1.x-dev

3. Install the mini module

4. Run the "Rebuild menu" option

Then the error should be gone.

I think that running the update.php script once (even when there is no changes) would rebuild the menus.

This being said, I do not know whether 2.x changes the database. I only used 1.x on my end. If you see some update_###() in the 2.x version that call db_xxx() functions, then it is likely that 2.x changed some of you database tables...

Thank you.
Alexis

bobburns’s picture

bobburns CreditAttribution: bobburns commented

Thanks for the fast reply

Yes that is what I did - but I did uninstall (un-check) and save the options - and then delete the folders with FireFTP and re-copied the new addresses extra and addresses modules folders back up to the server.

Yes, I had put 2.x over 1.x before I found out and realized the two were different versions.

Someone should just delete Addresses 2.x if it is dead. It certainly does not work.

The only way to know 2.x is dangerous is when you get into the modules node and there is a 1.x to 2.x database update feature there.

The mini module solution did not fix the cron issue on the Status Report page, NOR the menu issues of the second addresses extra not showing in the edit function of the account settings.

Do these Addresses-Extra values go anywhere useful right now - as I said they do not even show up in the "edit" function of the account - only on NEW ACCOUNT registration.

Who would know what this cron issue is? it is the only thing in the way right now

FOUND ANSWER TO CRON ISSUE

updated i18n to the current dev version and then pressed the "Variables cleanup" button on /admin/settings/language/i18n/variables

AlexisWilke’s picture

AlexisWilke CreditAttribution: AlexisWilke commented

Oh! I see what you're saying. i18n will save some info about different modules supporting translation and when you uninstall them, i18n doesn't really know about it... So you have to do some cleanup by hand to make sure it gets fixed.

Thank you for letting us know.
Alexis

AlexisWilke’s picture

AlexisWilke CreditAttribution: AlexisWilke commented
Title: Unknown column error » Unknown is_primary column error

Wanted to specify which column in the title...

lyricnz’s picture

lyricnz CreditAttribution: lyricnz commented

BTW, "uninstall" is not the same as unchecking the module on the modules page. you need to disable the module (uncheck and save), then switch to the Uninstall tab from the modules page. There you will see a list of modules that have been disabled, but not uninstalled. Select the module and uninstall from there. Do this *before* you remove the module source files.

The uninstall process does things like removing settings, tables created by the module, etc. Simply disabling the module does not do that.