News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

SOLVED - 207J database bug?

Started by CE WebDesign München, June 28, 2012, 20:35:51 PM

Previous topic - Next topic

CE WebDesign München

EDID: SOLVED for me in 208d+e (no more pingpong:)


when using tool "Install tables or if necessary update them"
i get this:

Table updated: Tablename gvd0t_virtuemart_waitingusers dropped: 0 altered: 1 added: 0
        Database updated

when doing again, same message again (so it was not altered?)

after using tool -> joomla database check gives 1 error
when joomla db-repair, vm-tool alters 1 again...
CE WebDesign München: https://ce-webdesign.de | Websites, eCommerce WebShops | Responsive Design | SEO

Milbo

I dont know what the database check of joomla is doing. the part which is changed is always just change to the same again. The recognisation that it is not the same is not working. Also not for the joomla one it looks like. again the idea rise in my head that they just use the database update I wrote for vm2 and enhanced it.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

CE WebDesign München

thanks for reply instantly,
modified post during that second a bit,

after joomla db-repair joomla says db ok!
then vm is altering again
then j finds error, repairs, sends ok, vm altering again...

so is there a bug,
do i need to do something?
CE WebDesign München: https://ce-webdesign.de | Websites, eCommerce WebShops | Responsive Design | SEO

Milbo

Look on the db, you will see the table structur does not change.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

CE WebDesign München

#4
i looked and yes,
table "waitingusers" no changes,

but vm-tool changes in "session" column 'data' from type 'MEDIUMTEXT' to 'TEXT' (that is no vm-table?)

the j-tool then gives this info (sorry, should have seen it before):

Table 'gvd0t_session' does not have column 'data' with type 'MEDIUMTEXT'. (From file 1.7.1-2011-09-15.sql.)

and it changes it back to 'MEDIUMTEXT' when pressed,
hm...
CE WebDesign München: https://ce-webdesign.de | Websites, eCommerce WebShops | Responsive Design | SEO

lysov

Since updating the tables (database Update tools) is not so clear. After this operation, I saw that in some tables field type of the `virtuemart_product_id` has changed from int (11) to int (1), here is the tables list with type of the `virtuemart_product_id` = int (1):
#__virtuemart_product_categories
#__virtuemart_product_medias
#__virtuemart_product_prices, etc

The situation is similar to the field `virtuemart_manufacturer_id`= smallint(1) at the #__virtuemart_product_manufacturers. The list goes on...

J! 2.5 & VM 2.0.7.f

Milbo

the difference between int 1 and int 5 for example is just the notation. int(1) shows for the number 5, just 5. int(4) stores 0005. The size is the same. It is not like with chars for example. char(10) are 10 chars.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

lysov

Different types for the same fields create confusion. As a result of several updates I have received such a structure:
table `#__virtuemart_vendors' : virtuemart_vendor_id smallint(1) UNSIGNED
table `#__virtuemart_vendors_ru_ru` : virtuemart_manufacturer_id int(1) UNSIGNED
etc : virtuemart_vendor_id smallint(1) UNSIGNED

The type of the fields `created_by`, `modified_by` and `locked_by` usually is set to int(11) (i.e. signed), but look at the `#__virtuemart_vmusers`: `virtuemart_user_id`  int(11) UNSIGNED