Upgrading from 5.x-1.x to 6.x-1.x fails due to pre-D5 image table

does it seem like everything is working correctly?

as per my thinking so many things are changed from 5 to 6 ...

so i think u cant change it..
u can upgrade to 5.14 but not to 6.x...

I am not sure but when i wants to do it i got the reply that u cant change it..

because there are lots of changes in it

see if you got the solution..

dhvani

@loko: please let us know if first upgrading to 5.x-2.x, then 6.x, works better.

Concerning the

u can upgrade to 5.14 but not to 6.x...

point, I'm assuming you've already read the http://drupal.org/node/340073 and http://drupal.org/upgrade/tutorial-introduction ? Yes, it can be easy to upgrade from just a core 5.x to the same 6.x , but it can be a problem if you are using a number of contributed modules.

If the http://drupal.org/project/image is the image one you've mentioned, seems it's still alpha for both 5.x-2.x and 6.x anyway, so probably something can go in an unexpectable way. But you can help its maintainers much if you will post the bugs found here : http://drupal.org/node/add/project-issue/image .

Turning this into the central issue, marking several others as duplicate now.

What do I do if I've already upgraded to 6.x? Going back to 5.x and upgrading image and then back to 6.x again isn't good since there's been a lot of activity on the site that will be gone if I revert to an earlier backup. No fun at all.
Isn't there some other way to fix this? Like removing the database table and reinstall image or something? Almost anything but reverting would be good.

I have the same issue as haeger, I can't go back to Drupal 5 to upgrade the module at this point, is there anything that can be done to fix the issue while on Drupal 6? Thanks.

Actually if you're having the images not displaying problem on Drupal 6, run the following query and it should fix it:

INSERT INTO image SELECT DISTINCT u.nid, f.fid, f.filename FROM files f INNER JOIN upload u ON f.fid = u.fid WHERE f.filename IN ('_original', 'thumbnail', 'preview')

Hope that helps, it worked for me.

Thank you.

You just saved me alot of time and frustration.

You are definatly my Hero for today :)

Can someone elaborate a bit more on what did not work and what needed to be done manually after upgrading? It looks like the upgrade path is missing a bit, but I do not understand the follow-ups in here. Thanks in advance.

Sun, apparently if you don't upgrade Image 5.1.x to 5.2.x before upgrading to 6.x, you'll need to connect to your MySQL server and execute the line of code in #12. (Though I thought I did upgrade all my 5.x modules first.) Otherwise, the nodes appear to have the files attached, but they don't display with the node.

subscribing

Better title.

We have spent many hours trying to unravel this problem. We have tried on local sites to go from 5.19 to 5.2 and we've gone from 5.19 to 6 and we have the same result -- lost images.

We have used the query above, but we are running into a MYSQL error that says, essentially, that the query failed because of a duplicate. And if we manually go in and remove the offending items (risky, in our mind) we just fail at another point.

We've seen reference in other forums to some query language to get around the dupes problem but those solutions have failed.

We are really desperate. And we're amazed at how many people are struggling with this. The implication in the image.module info on this site is that a) you really should go from 5.19 to 5.2 before upgrading to 6 and b) that process should be fairly simple. HOWEVER, we've found that it is disastrous. AND we've found the same disastrous result when we go right from 5.19 to 6.

We are techies in training. We've learned a great deal from this community and are great supporters of this software, but the amount of time, work and money we've spent to try to convert from 5 to 6 is staggering. The fact we are now at a point where the image module is blowing everything else up is beyond discouraging.

SO, does anyone have some help for us so that when we do the insert query above, we can deal with the subsequent dupe problem.

THANKS SO MUCH!

geoff

We have spent many hours trying to unravel this problem. We have tried on local sites to go from 5.19 to 5.2 and we've gone from 5.19 to 6 and we have the same result -- lost images.

We have used the query above, (#12: INSERT INTO image SELECT DISTINCT u.nid, f.fid, f.filename FROM files f INNER JOIN upload u ON f.fid = u.fid WHERE f.filename IN ('_original', 'thumbnail', 'preview') ) but we are running into a MYSQL error that says, essentially, that the query failed because of a duplicate. And if we manually go in and remove the offending items (risky, in our mind) we just fail at another point.

We've seen reference in other forums to some query language to get around the dupes problem but those solutions have failed.

We are really desperate. And we're amazed at how many people are struggling with this. The implication in the image.module info on this site is that a) you really should go from 5.19 to 5.2 before upgrading to 6 and b) that process should be fairly simple. HOWEVER, we've found that it is disastrous. AND we've found the same disastrous result when we go right from 5.19 to 6.

We are techies in training. We've learned a great deal from this community and are great supporters of this software, but the amount of time, work and money we've spent to try to convert from 5 to 6 is staggering. The fact we are now at a point where the image module is blowing everything else up is beyond discouraging.

SO, does anyone have some help for us so that when we do the insert query above, we can deal with the subsequent dupe problem.

THANKS SO MUCH!

geoff

Were these sites on 4.something prior to being on 5?

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/image/image...

it turns out that there used to be an {image} table on 4.5.

Committing this patch.

try this ! :

http://drupal.org/node/418220#comment-2849102

entry #20

Are people still having trouble with this?

Why isn't this code in image_update_5200() doing the job?

  // Versions prior to 5 had an {image} table which is no longer used on 5.1
  // but not removed.
  if (db_table_exists('image')) {
    db_rename_table($ret, 'image', 'image_old');    
    // Notify the user that their table has been moved. 
    drupal_set_message('Your existing {image} table has been renamed {image_old}.');
  }