Cannot insert configuration_key "" because it already exists

[RixStix]

Removed the code in Red. Tried again. Same error.

Success 3 statements processed.
Error ERROR: Cannot insert configuration_key "" because it already exists
Warning Note: 1 statements ignored. See "upgrade_exceptions" table for additional details.

"upgrade_exceptions" table just duplicates the ERROR: Cannot insert configuration_key "".....

[RixStix]

Am I barking up the wrong tree about the blank configuration_key that was inserted in Sept 2012 and contains a description found in the admin/modules.php file?

I've installed, deleted, reinstalled so many times that I may not remember all the details but that row seems to be the difference whether then responsive template installs correctly or not.

[DrByte]

1. Your immediate problem is NOT that you've already got a blank-configuration-key-entry in your database. But that also should not be. But fixing that is NOT the solution to your problem with your plugin.

2. The SQL script you're attempting to run is being intercepted by protective logic in the SQL Patch Tool that aims to save you from yourself when running patches that would throw errors. It specifically EXPECTS that any INSERT into the configuration table will be in a prescribed form/structure, and attempts to determine the configuration_key value from the query based on the format it expects the code to be in. And, for some reason yours is guessing a blank value for the key. And then when it queries the database to see if that entry is already there, it's finding a match and displaying the error message you're quoting.

Solution: run the query via phpMyAdmin instead.
Then fix whatever has caused your other configuration table entries to be damaged.

Then consider investigating why your site croaks with that SQL patch when most others do not. It would suggest someone has altered the sql patch tool, but that's only the outer layer of that very complicated onion.

[RixStix]

Thank you DrByte.

Obviously, I'm in over my head now. I was thinking that I had done good at finding matching incidents from the timestamps in the logs for when the blank configuration_key was generated.

At this time, installing any responsive template that requires those two patches has just fallen to the bottom of my priority list.

Finding and cleaning whatever mucked things up seems to be a more important issue.

[RixStix]

Then consider investigating why your site croaks with that SQL patch when most others do not. It would suggest someone has altered the sql patch tool, but that's only the outer layer of that very complicated onion.

I'm running the sql patch tool from within admin in a vanilla 1.5.1 install but with an updated 1.3.9h database.

I would think that should eliminate the possibility of an altered sql patch tool? BUT still indicates there is something not proper within my v1.3.9h database.

[rbarbour]

rbarbour can you take a look at this? I have just added the patch from the DIY responsive template default.

Thanks,

Anne

Syntactically the patch you've been given isn't properly designed to work in the SQL patch tool.

Try removing the first field from those INSERT statements, since it should never be supplied if it's just gonna be auto-incremented (null) anyway. I've highlighted them here, from your first code snippet:

INSERT INTO configuration (configuration_id,  configuration_title, configuration_key, configuration_value,  configuration_description, configuration_group_id, sort_order,  date_added, use_function, set_function) VALUES 
(NULL, '<font  color="#0044ff">ACTIVATE Responsive Template by selecting Column  Widths</font>', 'COLUMN_WIDTH', '2', ........

I get the same result with configuration_id VALUE NULL as I do if I remove it from the SQL patch

Result = highest configuration_id +1

I will update my template packages at my earliest convenience, IMO this has nothing to do with the blank configuration key issue of @RixStix

However, DrByte is the man and if he says "remove it", remove it.

Maybe DrByte can weigh in on how to go about doing this.

I would suggest including a patch to delete current configuration_key

DELETE FROM configuration WHERE configuration_key = 'COLUMN_WIDTH';

But this will have no effect if the configuration_key is blank

Changing the sql_patch is easy enough

INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added, use_function, set_function) VALUES
('<font color="#0044ff">ACTIVATE Responsive Template by selecting Column Widths</font>', 'COLUMN_WIDTH', '2', 'Width of the Left and Right Columns<br />0 = Use Default Template Settings<br />1 = 75px<br />2 = 150px<br />3 = 225px',@configuration_group_id, NULL, NOW(), NULL, 'zen_cfg_select_option(array(\'0\', \'1\', \'2\', \'3\'),');

Even though the SQL patch tool recognizes configuration_id as an AUTO_INCREMENT value and ignores it using the original patch.

I will copy this in the other thread as well in hopes to get a response from the man himself.

[rbarbour]

Removed the code in Red. Tried again. Same error.

Success 3 statements processed.
Error ERROR: Cannot insert configuration_key "" because it already exists
Warning Note: 1 statements ignored. See "upgrade_exceptions" table for additional details.

"upgrade_exceptions" table just duplicates the ERROR: Cannot insert configuration_key "".....

If you have another similar template installed such as the Responsive Apparel Boutique Template?

Then you will get an error stating:
Error ERROR: Cannot insert configuration_key "" because it already exists

Because you already installed the sql patch when installing the other Responsive Template.

[DrByte]

If you have another similar template installed such as the Responsive Apparel Boutique Template?

Then you will get an error stating:
Error ERROR: Cannot insert configuration_key "" because it already exists

Because you already installed the sql patch when installing the other Responsive Template.

Perhaps, but it should say "COLUMN_WIDTH" instead of ""