Default address ID is "0"

[mj999]

I'm not sure what I did to mess this up but, when a new account is created, the default address ID is posted as "0". That means the customer has no default address and nothing shows up on checkout shipping. Is there a way I can get it back to registering the default address at signup?

[logiczero]

I'm having this problem as well...

 

If it's a known bug, it would be great if someone could confirm it.

 

If not, it's line by line comparison with the original files...always a hoot.

[Guest]

If it helps, the sequence is

 

1. Create customers table entry with a default address of 0.

 

2. Create address book entry (setting customers_id to the value from customers).

 

3. Now that it knows the address_book_id for the default address, it goes back and updates the customers table entry.

 

I'm guessing that your problem lies with 3. Note: all 3 steps happen right in a row in create_account.php. The code for 2 and 3 (in the original files) is

      tep_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array);

     $address_id = tep_db_insert_id();

     tep_db_query("update " . TABLE_CUSTOMERS . " set customers_default_address_id = '" . (int)$address_id . "' where customers_id = '" . (int)$customer_id . "'");

Hth,

Matt

[logiczero]

I'm having address troubles elsewhere, and it occurs to me that I went through the pages where addresses are entered and changed the order of the fields so that they more accurately reflected how a U.S. mailing address looks.

 

Just rearranging some HTML, right?

 

Well, perhaps it's more complicated. I know there's that 'address_format' table in the database that arranges the field order of addresses based on the selected country. By manually arranging the entry fields, have I somehow created a conflict, which confuses the database and causes the default address ID to be set to 0?

 

If that's the case, then perhaps it's best to revert to the original pages, and then set the U.S. as the default country, so that the fields are in the "right" order? There's a tip somewhere on how to do that...

 

Given all that, it would be great if someone could confirm that these changes are a potential problem...at least I would know to go back and start over.

[logiczero]

 ? ? ?tep_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array);

? ? ?$address_id = tep_db_insert_id();

? ? ?tep_db_query("update " . TABLE_CUSTOMERS . " set customers_default_address_id = '" . (int)$address_id . "' where customers_id = '" . (int)$customer_id . "'");

Thank you for your reply Matt.

 

I found the code you pointed out, and it seems to be identical in my create_account.php file.

 

The notable difference still seems to be the reordered address fields...

[Guest]

You might want to turn on query logging in admin. It sounds like the address_book insert is failing. Thus, the insert_id is 0 (no insert performed). Query logging might show you what's failing.

 

Hth,

Matt

[logiczero]

Thanks for the tip on query logging...that'll come in handy.

 

Looking at the log, the address insertion seemed to work fine (i.e. the Result was 1). What seems to not be working properly is the line

$address_id = tep_db_insert_id();

which seems to return 0...

 

So instead, I store the return value of

tep_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array);

 

So now my code looks like

$address_id = tep_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array);

//$address_id = tep_db_insert_id();
     
tep_db_query("update " . TABLE_CUSTOMERS . " set customers_default_address_id = '" . (int)$address_id . "' where customers_id = '" . (int)$customer_id . "'");

Seems to work OK.

[logiczero]

WHOA!

 

Turns out that little code change in the last post only works because my address_book table was messed up: both address_book_id and customers_id were listed as primary keys. I think that error got introduced during one of the upgrade processes...

 

Anyway

      tep_db_perform(TABLE_ADDRESS_BOOK, $sql_data_array);

     $address_id = tep_db_insert_id();
     
     tep_db_query("update " . TABLE_CUSTOMERS . " set customers_default_address_id = '" . (int)$address_id . "' where customers_id = '" . (int)$customer_id . "'");

is the correct code, not the stuff I posted above.

[cwdmark]

this is a bigger problem than what has been addressed! by all means this should have affected everyone upgrading from an older version of oscommerce to 2.2

 

THANK YOU FOR POSTING THIS..... i spent last 4 hours trying to figure out, replacing db's and etc. and it was something as simple as a primary key.

 

this should be on the home page of oscommerce! everyone upgrading will have the same problem....

 

-m

[cwdmark]

also, i was testing out the site just before releasing it, and something else has changed:

 

the primary key in orders_status_history

 

changed from orders_status_id to orders_status_history_id

[logiczero]

To be honest, I'm not sure exactly how I ended up with this bug in my database. In fact, I wasn't even sure which old version of osCommerce I was upgrading from! (it was just a default install provided by my host)

 

What I can tell you is this:

I stumbled across the bug (and its fix) by opening oscommerce.sql, found in the \catalog\install\ directory of a freshly unzipped osCommerce download. By taking a look at the SQL required to create the database and comparing it with what was actually there, I noticed the discrepancy.

 

I have only a basic knowledge of SQL, but with the aid of phpMyAdmin, it was pretty clear what was wrong. I certainly don't know enough to recommend making changes to the default osCommerce installation/upgrade process, if in fact it is really a bug.

 

I hope that's enough information to help you on your way. Perhaps other people with more expertise can add other thoughts, and/or take a look at the osCommerce upgrade code to see if it contains this bug.

 

Let us know how things turn out.

 

P.S. I too had some weirdness with order_status_history, and I remember changing something to make it fit what the PHP code expected. I should probably have another look...

 

P.P.S. I've had the luxury of learning all these things while working on a site that isn't live yet...these are some pretty nerve-wracking changes to make to a live site!