Quote Originally Posted by luckystu View Post
We ran the query from phpmyadmin and it says it was successful, however we still can't find the results. Talked with our hosting tech support and they said the results should display right after the query is run but they do not. We used your code from above, mc, inserting the proper DB_PREFIX identified in both configure.php files. So as a hypothetical example, if we want to use "flowers" as a category name, which had been previously created and then deleted but is still not being "released" due to a mapping conflict, this is the query executed:

SELECT uri FROM (our DB_PREFIX)_ceon_uri_mappings WHERE uri like '%flowers%';

Is this correct and where would the query results be located? Sorry this is taking much longer than expected, really appreciate your help!
If you have accessed phpmyadmin, on the left side have selected not only the database associated with this site, but also the table (DB_PREFIX)ceon_uri_mappings and then on the right side selected the button/option along the top to run a sql query and entered into the query (let's assume the prefix is 'fun'):
Code:
SELECT uri FROM funceon_uri_mappings WHERE uri LIKE '%flowers%';
and then executed the query.

Then I too would expect the results to be provided below the representation of the query. Those results may be a statement of 0 results returned (or something similar) or 1 or more results in a column with the heading of the column being uri and each row showing the full content of the field returned.

If, in this case, the database being viewed is the active database that is reporting the attempt to duplicate mapping, then there should be at least one result that comes back.

Note the minor difference in how I represented the DB_PREFIX being used compared to how it was previously represented. ((DB_PREFIX)ceon_uri_mappings as compared to (DB_PREFIX)_ceon_uri_mappings) While this may not seem to make a difference between you and me, it is important for others that may try to follow this. ZC does not add the underscore between the prefix and the table name. If one is to use a prefix, adding the underscore (_) at the end makes it easier for other database manipulations at some point in the future, but there is no requirement for there to be one. Nor is there a requirement to have/use a value in the DB_PREFIX.