News:

Support the VirtueMart project and become a member

Main Menu

Upgrade warning from 3.0.6.4 to 3.0.8

Started by Nilsy, April 21, 2015, 12:36:39 PM

Previous topic - Next topic

Nilsy

I had VirtueMart 3.0.6.4 installed on Joomla 3.4.1

Upgraded now to the 3.0.8.
I install the .com first, then the .aio, and lastly the .tcpdf
However, the .com gives an error:

Warning
Duplicate entry 'delimiter_sendregistration' for key 'name' SQL=ALTER TABLE `jos_virtuemart_userfields` ADD UNIQUE KEY `name` (`name`)


And under that is states:

Error
Error installing component


Strangely, the site IS still working, and the component shows that the Virtuemart IS updated.
Is this something to worry about?

Linux: 2.6.32
PHP: 5.3.29
Web server: Apache

Studio 42

Hi,
I don't know, if all is updated, what you can do is to copy files from  .com zip pack in the right directories
and go to migration, and click update tables....

Milbo

Quote from: Nilsy on April 21, 2015, 12:36:39 PM
Warning
Duplicate entry 'delimiter_sendregistration' for key 'name' SQL=ALTER TABLE `jos_virtuemart_userfields` ADD UNIQUE KEY `name` (`name`)


It means, it cannot give the column 'name' the property unique, because there is already something not unique there.
=> delete the "right" delimiter_sendregistration column
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Nilsy

Hm...
Here's a screengrab of the SQL:

Which row to delete?
23 or 41, or both?

Nilsy

Ok... I deleted the one without the virtuemart start...
Re-installed, and a different table gave the same response... so, around 5 tables all gave similar reports!
I deleted these, (which were somehow duplicates??), and the installation went fine.

No clue as to why this was duplicated in the first place.
Anyway, thanks Milbo for the tip that made me look in the right direction.

stawebnice

I get the same error.
Using the database update tools Install or if necessary update all tables shows the error too: http://imtp.me/9egw02lj3.p

but despite the error,it seems to  be  installed: http://imtp.me/9egx02lj3
and when I make test order, it  works.
But I let you know if I find some issue.

stawebnice

The only remark maybe worth mentioning - I updated two eshops so far. The one that was created  with VM 3.0.7 originally, does not show the error.

The one with 3.0.6.4 that was migrated with Virtuemart Migrator by Daycounts does. So it might be related to the migration of customfields?

Nilsy

Well, I deleted the SQL stuff... and the Payment options vanished...
So, I had to re-install the backup.
So I'm back to square-1.

Studio 42

Hi,
If you have the original backup, try to update with some release before from the zip files, i read that this worked, but i cannot find the post.
donwload from here : http://dev.virtuemart.net/projects/virtuemart/files
first update from com_virtuemart.3.0.7.2_extract_first.zip
then com_virtuemart.3.0.7.4_extract_first.zip
and after you can apply the last com_virtuemart.3.0.8_extract_first.zip

i think on doing this steps the updater do the right updates and solve the problem.

Nilsy

Thanks for the tip Studio 42...
However, that didn't work. I went through every update available (3.0.7 => 3.0.7.2 => 3.0.7.4 => 3.0.8), to get to the 3.0.8, but the duplcate entry was always present on the .com installment.

But, as stawebnice says, it does actually seem to be updated.
I have even tested a purchase testrun, and it works.

Milbo

The problem is a 3rd party extension, which copies the userfields.

The table userfields, contains as ROWS, the COLUMNS of other tables. So when you add a new userfield => new columns are created on other tables.
There is a 3rd party, just duplicating the fields => VM tries to create a column in the table, which already exists => error.

To prevent this, I added the unique key word to the userfields table. So the effect is that the 3rd party cannot destroy it anylonger.
Negative effect is, that if you have this error already, you must fix it NOW.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

barbara80

unfortunately not figured out how to solve : - (
I do a backup of the site , so I can not go back.
I have to overwrite versions ?  starting from 3.7 onwards ?

Milbo

you have doubled columns, just remove the empty ones
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Nilsy

Ok Milbo, you are scaring me into thinking something serious is about to happen with my shop...  ;)

Quote from: Milbo on April 26, 2015, 12:22:31 PM
The problem is a 3rd party extension, which copies the userfields.

Negative effect is, that if you have this error already, you must fix it NOW.

I have been using VM since just after the Jurassic period of Joomla 1.0, and this means I have updated using the tools advised.
Most recently, from Joomla 2.5 to Joomla 3.4 using the Daycounts Migration component.
I think I used the same method to port from 1.5 to 2.5.
All seemed to go extremely well, until this recent update of VM.

But ok, looking at the table, it is clear that there are indeed duplicate stuff... but deleting the empty ones... hehe, is not helping.
I don't think these fields collect stuff, they are just fields that direct to the user database. (I think).

What would be MUCH appreciated help, is if you could point this out a little clearer...
Here is my screengrab of the table:

As you can see, Table 21 and 39 are both "phone_2", but the second one is "phone_2-1", which tells me it really wants to be deleted.
Am I correct in thinking that this "-1" at the end of the name is an indication to delete it?
Likewise: Table 22 and 40 (fax and fax-1) etc.

But, looking at Table 26 and 51, they seem to be identical... without any "-1" after the name?
Is that just a case of deleting one, and testing the result... if it works "good", if not, stick in the backup, and try again?