[Skip to main content](#vessel-content)

#   Deleting tax zone deletes zone from all addresses

##

- **[EdQ](/forum/user/6930-edq "View EdQ's Profile")**
- [![EdQ's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar6930.jpg)](/forum/user/6930-edq "View EdQ's Profile") Topic Author
- [ Offline](/forum/user/6930-edq)

Less More

- Posts: 14
- Thank you received: 0
-
- [](http://www.eduardqualls.com)
-

14 years 6 months ago [\#46150](#46150) by [EdQ](/forum/user/6930-edq "View EdQ's Profile")  *[Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46150 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, Ed")* was created by *[EdQ](/forum/user/6930-edq "View EdQ's Profile")*

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

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[EdQ](/forum/user/6930-edq "View EdQ's Profile")**
- [![EdQ's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar6930.jpg)](/forum/user/6930-edq "View EdQ's Profile") Topic Author
- [ Offline](/forum/user/6930-edq)

Less More

- Posts: 14
- Thank you received: 0
-
- [](http://www.eduardqualls.com)
-

14 years 6 months ago -  14 years 6 months ago [\#46179](#46179) by [EdQ](/forum/user/6930-edq "View EdQ's Profile")  Replied by *[EdQ](/forum/user/6930-edq "View EdQ's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46179 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;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

Last edit: 14 years 6 months ago by [EdQ](/forum/user/6930-edq "View EdQ's Profile").

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[EdQ](/forum/user/6930-edq "View EdQ's Profile")**
- [![EdQ's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar6930.jpg)](/forum/user/6930-edq "View EdQ's Profile") Topic Author
- [ Offline](/forum/user/6930-edq)

Less More

- Posts: 14
- Thank you received: 0
-
- [](http://www.eduardqualls.com)
-

14 years 6 months ago -  14 years 6 months ago [\#46181](#46181) by [EdQ](/forum/user/6930-edq "View EdQ's Profile")  Replied by *[EdQ](/forum/user/6930-edq "View EdQ's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46181 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, 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=&gt;Display=&gt;Custom Fields=&gt;address\_state=&gt;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

Last edit: 14 years 6 months ago by [EdQ](/forum/user/6930-edq "View EdQ's Profile").

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[nicolas](/forum/user/63-nicolas "View nicolas's Profile")**
- [![nicolas's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar63.png?1793428657)](/forum/user/63-nicolas "View nicolas's Profile")
- [ Offline](/forum/user/63-nicolas)

Less More

- Posts: 86320
- Thank you received: 14279
-
-

14 years 6 months ago [\#46182](#46182) by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")  Replied by *[nicolas](/forum/user/63-nicolas "View nicolas's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46182 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, Ed")*

Hi,

If you deleted some of the default zones or zone links in HikaShop, the simplest is to go in the database, empty the hikashop_zone and hikashop_zone_link tables. Then, install again your package of HikaShop and the zones will all the loaded again in the tables as it is by default.
The reference to the zones in the addresses will match again.

In most use cases of HikaShop, you should not have to delete any default zone data or links and just unpublishing the zones you don't need should be enough.

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[EdQ](/forum/user/6930-edq "View EdQ's Profile")**
- [![EdQ's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar6930.jpg)](/forum/user/6930-edq "View EdQ's Profile") Topic Author
- [ Offline](/forum/user/6930-edq)

Less More

- Posts: 14
- Thank you received: 0
-
- [](http://www.eduardqualls.com)
-

14 years 6 months ago [\#46183](#46183) by [EdQ](/forum/user/6930-edq "View EdQ's Profile")  Replied by *[EdQ](/forum/user/6930-edq "View EdQ's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46183 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, 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?

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[nicolas](/forum/user/63-nicolas "View nicolas's Profile")**
- [![nicolas's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar63.png?1793428657)](/forum/user/63-nicolas "View nicolas's Profile")
- [ Offline](/forum/user/63-nicolas)

Less More

- Posts: 86320
- Thank you received: 14279
-
-

14 years 6 months ago [\#46185](#46185) by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")  Replied by *[nicolas](/forum/user/63-nicolas "View nicolas's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46185 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, Ed")*

HikaShop does not delete anything on its own.
There is no code which would delete a zone when a tax is deleted.

Reinstalling HikaShop does not delete anything. When you update HikaShop, you use the same install package you would use for a fresh install or for an update. And when you update HikaShop, it does not deleting anything either.

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[EdQ](/forum/user/6930-edq "View EdQ's Profile")**
- [![EdQ's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar6930.jpg)](/forum/user/6930-edq "View EdQ's Profile") Topic Author
- [ Offline](/forum/user/6930-edq)

Less More

- Posts: 14
- Thank you received: 0
-
- [](http://www.eduardqualls.com)
-

14 years 6 months ago [\#46188](#46188) by [EdQ](/forum/user/6930-edq "View EdQ's Profile")  Replied by *[EdQ](/forum/user/6930-edq "View EdQ's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46188 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, Ed")*

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.

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

- **[nicolas](/forum/user/63-nicolas "View nicolas's Profile")**
- [![nicolas's Avatar](https://www.hikashop.com/media/kunena/avatars/resized/size144/users/avatar63.png?1793428657)](/forum/user/63-nicolas "View nicolas's Profile")
- [ Offline](/forum/user/63-nicolas)

Less More

- Posts: 86320
- Thank you received: 14279
-
-

14 years 6 months ago [\#46190](#46190) by [nicolas](/forum/user/63-nicolas "View nicolas's Profile")  Replied by *[nicolas](/forum/user/63-nicolas "View nicolas's Profile")* on topic *[Re: Deleting tax zone deletes zone from all addresses](/forum/3-bug-report/46150-deleting-tax-zone-deletes-zone-from-all-addresses#46190 "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 &#91;prefix&#93;&#95;hikashop&#95;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&#95;id, nor for zone&#95;namekey, but had instantiated a row with new settings instead of re-reading the default/shipped values.  Will it corrupt the data in &#91;prefix&#93;&#95;hikashop&#95;zone&#95;link if I go into SQL and insert a row with the correct values (from administrator/components/com&#95;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&#95;id is a key into tax information held by another database, so I'm reluctant to do it without checking.  Thanks, Ed")*

Well, I want to believe you but I'm not able to reproduce that bug. Please provide a step by step to reproduce it and I'll look at it.
I created a tax zone, assigned it to another zone as a subzone, deleted the tax zone and the parent zone was still there.

I'm definitely not a god and make mistakes like anyone.

Please [Log in](/login?return=aHR0cHM6Ly93d3cuaGlrYXNob3AuY29tL2ZvcnVtLzMtYnVnLXJlcG9ydC80NjE1MC1kZWxldGluZy10YXgtem9uZS1kZWxldGVzLXpvbmUtZnJvbS1hbGwtYWRkcmVzc2VzP3RtcGw9bWFya2Rvd24=) or [Create an account](/component/users/registration?Itemid=101) to join the conversation.

Board Categories HikaShop Install &amp; Update Product &amp; Category Display Content Creation Sales and Orders Orders management Reports &amp; Statistics Customers Checkout Payment Methods Shipping Methods Import &amp; Export (CSV, XLS…) Specific Features Affilation Taxes Wishlist Vote Carousel &amp; Slider Mass Actions Filters &amp; Search Discount &amp; Coupon Feature Request Integrations Showcase General Talk about HikaShop Development HikaShop 3.0 Beta Translation Commercial Jobs HikaShop Components HikaMarket Market: Feature requests Market: How to? Market: Bug Report HikaSerial General talk about HikaSerial Serial: Bug Report Serial: How to? Support en Français de HikaSerial (French Support) HikaSubscription HikaAuction Auction: Feature requests Auction: How to? Auction: Bug report Hikashop around the world Support en Français (French Support) Russian FAQ. Курс выживания с Hikashop. Частые вопросы и о Расширения Hikashop Наши сайты на Hikashop 日本語版サポート(Japanese Support) Thai German Archives Bug Report How to?

[](/forum/topics/feed/mode-topics?format=feed&type=rss)

Time to create page: 0.074 seconds

[Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)

[](#top)
