Deleting tax zone deletes zone from all addresses

In trying to set up a tax zone I deleted what I thought was simply a tax subzone for a US state.

To my surprise, this actually deleted the data for this subzone from all address handling, as well.
(The row in [prefix]_hikashop_zone is gone.)

Although I understand the need to keep this large amount (4250 rows) of data from being replicated, it surprises me that module-instantiated values would be compromised by this kind of procedural cross-contamination, particularly when single data points are used for two or more completely separate reasons. I would have assumed that static address information wouldn't be affected by changes made in setting up tax information.

After that, when I inserted the name for the subzone, the table didn't contain the original values for zone_id, nor for zone_namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.

Will it corrupt the data in [prefix]_hikashop_zone_link if I go into SQL and insert a row with the correct values (from administrator/components/com_hikashop/helpers/update.php, and delete the non-standard row? Or do I need to uninstall/reinstall HikaShop again, to make sure it's in a stable state? I don't know if zone_id is a key into tax information held by another database, so I'm reluctant to do it without checking.

Thanks,
Ed

Here is some additional info, and my next step--

The original key for the state zone is still retained as a link-entry in the table [prefix_]hikashop_zone_link, despite the fact that the row that it references has been removed from the [prefix_]hikashop_zone table.

The key for the new zone's row in [prefix_]hikashop_zone is inserted into [prefix_]hikashop_zone_link. (This is the zone I inserted trying to restore the one that was removed.)

I will use the data from update.php to run an SQL query to re-insert the original values into the [prefix_]hikashop_zone table. (It's very helpful that the data in update.php is clear text, and not compressed or encrypted!) I will then remove the link to the non-standard row that is in the link table. I believe that, since the original zone's link is still in place, this will restore the state of the zones so that no reinstall is required. (Please advise if that isn't the case!)

Merci bien,
Ed

It looks like the operations I listed above worked.

For the benefit of anyone who has accidentally deleted the standard, HikaShop-defined values of a zone, here is an outline of the restoration, using example values.
The following information is for illustration purposes only: I assume no responsibility for anything you may do to any websites. By reading the following you agree and affirm that you assume all liabiility for any of your actions that may mimic, reference or be influenced by the information given below, and for any and all correlative or derivative actions, conditions or situations. D*mned American lawyers.

Example values:
local table prefix (yours should vary): xxxx4
(the following are system-standard or system-generated values)
Deleted zone_id: state_Texas_4307
Created zone_id: state_Texas_2042366762
Example values will be italicized below.
BACKUP YOUR DATABASE FIRST!
Take your shop offline so no one can step on the database while you're working on it.

1. Locate the data entry for the zone in administrator/components/com_hikashop/helpers/update.php and write down those standard values. (Do not ever edit this file!)
2. To help verify the SQL steps below, go ahead and recreate the zone inside the HikaShop admin using as many of the standard values (from the step above) as the entry form allows.
3. Check the drop down list for the zones as displayed in the address fields' drop-downs. (e.g., HikaShop admin=>Display=>Custom Fields=>address_state=>Default value) Your new entry should be there, but you may have to search for it because the list will no longer be sorted in exactly the same way because it is (apparently) done on the zone_id column, and your new entry will have a zone_id that no longer fits within the sorted range of values of those already in the built-in list.
4. Go to your site's SQL database control, hopefully this is phpMyAdmin.
5. Verify that your new entry is in the zone table: SELECT * FROM 'xxxx4_hikashop_zone' WHERE 'zone_name'='Texas' You should get one row. Write down the values from all the columns.
6. Verify that your new entry is in the zone-linking table: SELECT * FROM 'xxxx4_hikashop_zone_link' WHERE 'zone_child_namekey'='state_Texas_2042366762' You should get one row. Write down its data entries.
7. Verify that the entry of the original zone is still in the zone-linking table: SELECT * FROM 'xxxx4_hikashop_zone_link' WHERE 'zone_child_namekey'='state_Texas_4307' You should get one row.
8. Go back to the zone table and insert the original row's values: INSERT INTO xxxx4_hikashop_zone (zone_id, zone_namekey, zone_name, zone_name_english, zone_code_3, zone_type, zone_published, zone_currency_id) VALUES (4307, 'state_Texas_4307', 'Texas', 'Texas', 'TX', 'state', 1, 0)
   (Note: if your zone's data has a zone_code_2 entry, add that column name to the VALUES list, and put its value in the same relative position in the actual value list as the column name is in the VALUES list. Any column for which there is no data can be omitted from both lists.)
9. Now delete the row of the new zone that you created: DELETE FROM xxxx4_hikashop_zone WHERE zone_namekey='state_Texas_2042366762'
10. Return to the zone-link table and delete the link to the row you just deleted: DELETE FROM xxxx4_hikashop_zone_link WHERE zone_child_namekey='state_Texas_2042366762'

This should have those two tables reset to their original data values.

I realize that this is a daunting set of operations, particularly for those who haven't used SQL before. However, it is important that you get some experience with SQL and familiarity with its basic operations at the least. The HikaShop team can't possibly cover every exigency that might arise, so you may have to get your hands dirty, working in the grime of the SQL engine to fix things as they hit your site.

Ed

See the top of the thread.

The problem was not with ignoring values, but that HikaShop itself DELETED a zone value when only a tax entry was supposed to have been deleted. This is why this was filed as a bug.

Will reinstalling HikaShop not delete everything else we have done in setting up the shop?

Well, I don't want to believe that you're actually calling me a liar, but HikaShop DID delete a zone when a tax zone was deleted.

As a programmer with 20+ years experience, I know that even the best developers overestimate the abilities and behavior of their code, and can forget, or fail to identify, side-effects in their codebases that they swear the code is incapable of effecting. That is, until a bug proves them wrong. This is a bug.