EMS Shipping covering all weights

[ridexbuilder]

Hi,
I know there have been numerous threads about shipping and weights (particularly in oscommerce) but trying to find a specific answer has been elusive.
Time is of the essence for me, so getting something resolved quickly will be extremely useful.
EMS (Japan) has a vast range of weights/prices in their shipping rates, which are all required from 300g, all the way to 30Kg.
From what I've been able to find out so far, oscommerce (and derivatives) are unable to handle weights of less than 1 unit, for example 0.3, 0.5 etc. Weights under 1 are rounded up to a value of 1.
However working in grams (from 300g to 30,000g) makes the definition of the zones table too large (probably an excess of characters), filling the field.
My questions is:
What is the preferred/recommended option to overcome this? Should I just modify the zones database table to accommodate a larger field?

Thanks upfront for any insight.
EJ

[michael_s]

Yes, that sounds like it would be the simplest method to resolve your issue. Check to see what the current field size is and then increase it accordingly.

[ridexbuilder]

Sorry, silly question (again):
What table in the database are the weight values held in? There isn't one called shipping (too obvious, I guess).
Have looked in zones, geo_zones and zones_to_geozones with no luck.
The expression "Can't see the wood for the trees" springs to mind.
EJ

[ridexbuilder]

Fortunately, with a lot of head scratching, I can now answer my own question.
The shipping table values are stored at the far end of the configuration table (along with stacks of other stuff) and is currently set as varchar(255). After consulting an online SQL definition of varchar, it's possible to raise this field to a max. value well in excess of what is required A semi-educated guess suggests that 640 characters should be sufficient to hold the EMS table but I'll update this post if more is needed (for the benefit of others).

EJ

[ridexbuilder]

It seems as though varchar is restricted to 255 in MySQL (unlike others)
Switching the field to TEXT has resolved the field size issue and shipping weights are matched correctly to prices However, now the product weight maxes out at 999.99 - great! It's a shame the shipping zone doesn't see those two decimal places, and so, the saga continues...

[ridexbuilder]

OK I had it with this train of thought - the modification of yet more fields smacks of using a sledgehammer to crack a nut!
This should be resolved MUCH easier by just removing the stupid rounding up of the weights. Trying to find a straight answer on this issue is however nigh on impossible. The zones table even suggests removing rounding in shipping.php, where there is no apparent code relating to rounding. 2 hours worth of web searching and still no further forward
I can see why people become frustrated....

[hemma]

Hi - Just had the same problem - we sell a range of items from 10gms to 100kgs. The weight is in gms on the site, so 100kgs = 100000gms, BUT oscmax changes this to 999.99. Only found this when a customer order a heavy item we had just put on and instead of £39.99 shipping it was £2.99! I have solved this by going into the SQL database, looking in products table and changing products_weight form decimal(5,2) to decimal(7,0). Hope this helps - and please back up the database first just incase!