dblayoutstrict does not work / not able to login after sql error in tableupdater

[malaclypse]

Hello,

The fields for example for the product short description are just too small for my needs. I tried changing that by setting the dblayoutstrict to 0 in the virtuemart.cfg and renew the config by file in the db tools.
However some fields are still reset after saving the configuration.

Also be carefull not to produce any errors in the tableupdater.php. I wasn't able to log into the administration backend after producing an sql error there (repeatedly). Did not look deeper into this and just restored the backup. An error there is relatively easy to produce, for example if you set the dbpsdescsize in the virtuemart.cfg to a higher value, you get "ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs"

My solution for now is to crop out the responsible code in the function updateMyVmTables in the tableupdater.php. Downside sure is, that i have to do that before installing every new version.

Or is it possible to override the tableupdater.php? Placing a file in the template in html/com_virtuemart/helpers does not work.

Versions: Joomla 2.5.4, VM 2.0.4

[Studio 42]

It's possible we introduce a Function overider, but it's only a idea for now.
For now you must handle with the original one.

[Milbo]

No, this works as expected, just not so easy.

You add in your config file virtuemart.cfg the entry dblayoutstrict = 0 or maybe dblayoutstrict = false, if this not work use FALSE. Anyway one guy found it out himself lately.

Save the file and go to the tools and use "Renew config by file". Then use "Install tables or if necessary update them". Then you should get the lose dblayout, which is a bit slower but allows very long texts.

[Snarkelton]

If you do this as recommended by Milbo, be sure you back up your ENTIRE SITE before trying it.

I did as recommended and it crashed my entire site. I lost several weeks worth of work because I followed this instruction.

[RobertL]

Figured I'll give it a shot. Sadly, it's not a solution, neither does it work, but it does break a lot.

dblayoutstrict=0 breaks VM completely (no time to replicate it again to show error message)

dblayoutstrict=false
1. All virtuemart tables ending with _en_gb get broken. It's an easy fix if you updated your database, simply repopulate from backup and they're back
2. Configuration file goes back to 'factory default'
3. Table waitingusers also gets modified, but since it was blank to begin with, I couldn't tell what effect it had if any

Leaving such a short character restriction as default is quite bad. If idea is to speed up performance, it would be better to have it available as an option in config to restrict in favor of performance

[RobertL]

Thought I'd try a simple trick I used in VM1.1.x a while back.

Just change product_desc field type from varhcar to text in yourprefix_virtuemart_products_en_gb table and problem solved. No changes in VM required and it works, limit is now 65000 (don't worry if it shows 0) instead of 18500. Always back up before you do anything in database just in case.
You should be able to apply same thing to other tables where required.

[Milbo]

Yeh, but when you update your vm, the tables will be truncated again, for that you need the dblayoutstrict=0

[d0ublezer0]

Still Not working.
Upgrading from 3.0.16 to 3.0.18 - tables truncated
tried
dblayoutstrict=0
and
dblayoutstrict=false