Orders incrementing by 2

[Congerman]

OK Many thanks

[DrByte]

What version of Zen Cart are you using?

You said that your host implied that they're using 2 servers, with one set to use odd numbers and the other to use even numbers, for the purpose of load-balancing .... but if they're truly doing load-balancing then why are all your numbers odd and none even? It suggests that they're not actually "using" the load-balancing.

[Congerman]

using 1.50

They say " In a two-server setup, server 1 inserts 1, 3, 5, 7, etc. and server 2 inserts 2, 4, 6, 8, etc."

They now suggest that i buy a dedicated server to overcome the problem Sales tactique or what?

[DrByte]

Ya, great sales tactic. Not.

Dump them.

Doesn't explain why you're only getting odd-numbered records. If you were truly getting load-balanced traffic, as in *actually* using *both* servers, then you should be at least getting "some" even-numbered records as well.
Sounds like they've set up their "load balancing" to not actually "balance" the load, but instead to only "offload" traffic to the 2nd server only when the 1st server is deemed "busy" according to some arbitrary threshold.
Poorly architected plan IMO.

In time you'll find that other customers of your host will also complain, and get the same response back. And probably just get the up-sell, instead of getting their server architects to rebuild things in a way that works best for the customers.

[Congerman]

Agreed

Why did you ask my zen version?

[DrByte]

While one could fudge the ZC code to force auto-incrementing by 1 regardless of the server's global setting, in your multiple-master situation, that is indeed likely to cause replication conflicts ... and then you'll have an even uglier mess on your hands later.

They probably think that multiple-master is the "safest" way to do things because it doesn't require that customers rewrite all their PHP code to work in a master-slave format. And, while it's true that there's no PHP code rewriting needed to use their multiple-master-solution-by-fudging-autoincrementing, there IS a BIG downside: the very problem you've reported ... gaps in record numbers when the code is designed to work with database-driven incrementing dependent on using auto-increment values instead of more complex methods like building custom triggers and stored procedures.
It also means your Zen Cart tables can only store half as many "maximum number of records" as they're designed to hold. So, you may have to eventually alter the db schema to allow for much larger field types on the fields using auto-increment properties.

It would be MUCH safer to have a proper master-slave setup. But that requires rewriting the PHP code to do SELECT statements from "slave" servers, and do INSERT or UPDATE statements on the "master" server only. And rely on scheduled replication cycles to keep both servers updated in "almost-real-time" (which is adequate for almost everything).

Zen Cart v1.x is written to assume a single-master-only MySQL server configuration. And, IT DOES WORK FINE in your host's odd autoincrement situation, but you will have to put up with the gaps in numbers all over the place. (order numbers, customer numbers, zone numbers, product numbers, category numbers, order-status-numbers, etc.)

Zen Cart v2.x (currently under development, not ready for viewing) is written to support master-slave configurations, and also has a number of things built-in to insulate against things like your auto-increment anomaly ... well, for order-numbers anyway, but not yet for other data records.
We'll add a task to explore handling those differently for cases such as what your hosting company has chosen. But it won't likely get backported to v1.x because it would require sweeping code changes on both catalog and admin sides.

[DrByte]

Why did you ask my zen version?

I was toying with an idea to force an override of the global configuration. But unless you can find a way to guarantee that your site will not actually use the 2nd server (the one that is set to issue "even" numbers), I suspect it'll be dangerous to do such an override, lest you end up with replication conflicts that will make you and your hosting company have to talk regularly and sort out duplicate records.
And, since duplicate records could mean that you could have two customers both legitimately get the same order number, and even the same customer number, that would all be very bad.

[Congerman]

Sounds like vs 2 will be the way to go if it will get around this as I presume other hosting agents will be going this way as well.

out of interest what are the maximum allowed records in the zen database?

As it stands will vs 1.5 be able to upgrade to vs 2 easilly or will it require a complete reinstall and re customisation and database transport

[DrByte]

out of interest what are the maximum allowed records in the zen database?

The maximum allowed is based on the field definitions for each table. And some tables have different structures.

will vs 1.5 be able to upgrade to vs 2 easilly

Answers about v2 would be premature. As with any upgrade, there will be some need to redo things in templates and customizations. And, like any major version number upgrade, it is likely that some plugins will also need refining.

will vs 1.5 be able to upgrade to vs 2 easilly or will it require a complete reinstall and re customisation and database transport

Like all ZC upgrades, data will be preserved.
Your question suggests that you view upgrades differently than I do. Even current-version upgrades don't require any complete reinstall nor do they require any database transport if you do them the way I recommend: http://www.zen-cart.com/entry.php?3-...d-of-upgrading

[Congerman]

Many thanks for all your imput, Looks like I will be using vs 2 as and when it is available

about the true dual server and incrimenting they say this about the numbering and always getting odd but no evens

That would be true in the case of web-traffic balancing, which uses normal multi-master balancing, however the setup of MySQL server means it doesn't dynamically swap between them. I'm sorry that this has interfered with the ordering setup of your Zen sites, but as I have said previously this is a common occurrence on any servers that are load-balanced.