Exactly what I was looking for. Thanks, Lyle!

(Told you it'd be a quick one)

I am bumping this to see if anyone can help. I'm not in QUITE the same situation I was in the above post.

At this moment in time, I've switched all of the order_id table columns to BIGINT(15), and I am able to insert a NEW uc_order record directly into the database with a length such as "1190918241000149" - but something in the UberCart code is truncating anything greater than 2147483647, which is what integer values too large for PHP buffers default to when they have an overflow.

Uberdudes - any idea what functions might be getting called that would do this? I've run tests and I don't think it's any of the unserialize() functions; the only thing that seems to do it is intval() but, even after I have removed any instances of this function, the order_ids are still getting truncated.

This happens as an admin creating a new, blank order as well. Any ideas?

Any help is greatly, hugely appreciated!

Erik

Thanks Ryan!

That's a good idea, but unfortunately, one I'd like to use as a last resort. We have almost a year's worth of previous orders that use longer numbers (with a dash) and would like to keep the new cart system using something similar to what we (and our customers) are used to. This isn't to say we're married strictly to that, but again, it's more of keeping everything in order.

We have a ton of previous orders and customers, so the consistency is a bit of a priority for us.

The interesting thing is, when I create an order with a long number as I mentioned - the "edit order" screen comes up and says "Order number 1100827393000456 created" .. but when you back out and go to the "view orders" screen, that number doesn't exist and is instead replaced with the Overflow number.

So it appears to be something in the middle of the process which saves the order to the database. As I mentioned I can create a new database record directly, but anything created to the cart is truncated.

This is going to drive me nuts ... and it's probably something simple and obvious. My new goal in life is to find out what's causing this and fix it!

I knew it was something simple. The odd thing was I've done that before but not in combination with the bigint data type for the table columns.

That worked! I hope that it doesn't break anything else. I successfully created new orders (long order_id value, but no dash, as that breaks other functions such as order_load) as an admin and a customer. Also, I'll have to be careful when you guys issue updates, because that'll mean changing %d to '%s' all over again. =/

Thanks for the help!

Erik