Duplicate Model Numbers warning!

[jcurtice]

The thing is, checking to see if the RecordCount is greater than 1 means that the item/information has already been entered into the database and now must be addressed to remove the entry. The test of the entered (typed in) model information should be performed before the assignment of the data to the database so that it never gets added and that way the "user" can be shown an error message and allowed to return/re-enter the applicable data. From looking at this little snippet as it was rewritten, it appears that any number of duplicate model numbers could exist and as each one is added again, then the user is presented with the message of seeing which is where and does not exactly prevent the entry of the duplicate data.

As for the fields that are "missing", there are ways to add additional fields to the database or as has been chosen to use the existing fields differently. I'm sure I'm in a minority of users, but in dog rescue we don't exactly have "part numbers", so that additional field (or series of fields/array as couldn't in say the automotive business several part numbers all relate to a single product?) Isn't something we "need". I'm not saying that it shouldn't be added, but am offering a different perspective as this code is predominantly modified to support the majority although bug fixes are made for all (when they can be reproduced).

In fact for our rescue we created a new product type to address all of the information we need to capture, some of which is used for display, some for internal data tracking, some to be manipulated based on existing information entered on the form, etc... Seemed like the cleanest way to manage the information and maintain the database as normalized as possible.

Good point, but even displaying animals, unless you only have a few, it would be necessary to inventory them with a unique number of some sort.

We could disable the button to prevent the duplicate entry but I elected to just display a warning because if I prevented it then we would not be able to correct any that existed. We deal with tens of thousands of parts and part numbers and is very important to be able to locate them correctly when a sale is made. How did you add additional fields? Was it hard coded or a plugin? I tried some of the plugins but my site is a 1.3.8 to 1.5.0 upgrade and that seems to be a problem with certain plugins.

[mc12345678]

Good point, but even displaying animals, unless you only have a few, it would be necessary to inventory them with a unique number of some sort.

We could disable the button to prevent the duplicate entry but I elected to just display a warning because if I prevented it then we would not be able to correct any that existed. We deal with tens of thousands of parts and part numbers and is very important to be able to locate them correctly when a sale is made. How did you add additional fields? Was it hard coded or a plugin? I tried some of the plugins but my site is a 1.3.8 to 1.5.0 upgrade and that seems to be a problem with certain plugins.

So externally, yeah they are unique, they all have a name. :) sure it was a problem when five dogs came into rescue all with the same name over a period of four months or so, but publicly their name received a little character, so like instead of say Sally, she may be listed as Sallie-Mae and the other as just Sally, then the third as Sallie-Jean, just for fictitious examples... Internally, every dog is microchipped (policy of the rescue), so there is that unique information, also as for an Id number, the database generated product_id works for us. Even if there is a number "lost" or assigned to say us honoring a volunteer's lost one at least there are no duplicates... :)

Either way of addressing the duplicates requires the "finder" to take extra action. Some may skip the message and carryon with the transaction (highlighting the need to provide some sort of notification of duplicate existing), others will stop and do what is right. I can't say I know exactly your process flow for getting to thepoint of potential duplicates, but the earlier the issue can be identified, addressed, and prevented, the better off the final product. My thought was that at the time the most recent entry is made, and the button is pressed to add the product, either the current product or the previous "duplicate" was entered incorrectly. Generally speaking if all things to date have been properly entered then the current product is the one to "blame", and therefore it is the one that should be edited, with the remote possibility that the previous was incorrectly entered and somehow got past all of the quality control... My suggestion would be to address each new entry from that perspective and depending on the status of the previous data, to provide some sort of corrective measures when an issue is identified.

As for the extra fields, well, first of all, the origin of the upgrade should have no bearing on the ability to use current/future product if the current store is equivalent (or as patched better) than the files provided from the ZC site. Sure there may be some things that currently do not jive with other plugins, but there's probably a pretty good reason and more than likely an easy fix... So, that said, while it can be considered complicated by some, numinix offers a plugin to add fields to the database, which I have partially used in the past, but much like the above discussion, found myself using one field or another for something other than what it describes... (Work-arounds.)

So, I finally kind of got tired of it and saw some potential benefit for having our own data-type with the thought that I might be able to share it with other rescues. You know when you goto add a product, and to the right of the button saying something like new product there is a dropdown with five options? Well, I've added a sixth. It is primarily document data-type as it is more about the information than a "product". But used the wiki and FAQ area to address the new datatype and have been coding along to try to have it make sense.

In a way it is sadly like my first php coding. I learned php to be able to display this information about the dogs, so already had a sort of database (crude as it was) for the dogs. I had written an entry, modification, display script for the information to be "seen" on one site, but our cart is elsewhere. In order for the two to be merged,I wanted to do it right and have all of the information covered/controlled in one location rather than having to access multiple. So the existing/default product fields are used, as well as the product_description fields, but then there is additional information related to this product type that is captured in the additional tables associated with this product type. Currently we track four different types of "biographies", but only populate the database with the one(s) that contain data. The currently "active" biography is transferred into the product description field when the product is saved. That way, the default ZC description listing process doesn't need tampering. I also had gone beyond what has been seen at other rescue sites, in that the rescue collects information about a dog, thisincludes the "birth" (whelp) date. Everyone always asks, how old is the dog? Rescue can take a week to several months or more to find a suitable adopter... Our volunteers do enough and shouldn't have to update stuff like that, so a calculation is done on the birth date, to current date, and depending on status of the dog (adopted, or otherwise passed on) provide applicable information/modification of the text. This is something that is not necessarily inherent to ZC's datatypes, so required an additional calculated "field" (though the calculated result is not stored in the database, but it is a result of a function.)

There's some more development worthy to it, especially to support variations on the four biographies, as that could be more of an iterative process to accomodate any number of entries. Anyways, sorry rambled on some more.

Self designed additional fields to accompany a product type... Otherwise yes there are plugins. That will accomplish a similar goal. Somewhat depends on the needs/expectations/etc... On which way to go.

[jcurtice]

New update to prevent it from showing up on a product update

 // check for duplicates
$products_model = $_POST['products_model'];


$dups_query_raw = "SELECT products_model FROM " . TABLE_PRODUCTS . " WHERE products_model = :model ";
$dups_query_raw = $db->bindVars($dups_query_raw, ':model', $products_model, 'string');


$dups = $db->Execute($dups_query_raw);
if (isset($_GET['pID'])) {

}else{
if ($dups->RecordCount() > 0) {
  $trigger_error = '<span style="color: red; font-size: 20pt; background-color: #FFFF00">
  Product Model number ' . zen_output_string_protected($products_model) . ' already exists ' . $dups->RecordCount() . ' times!
  <a href ="' . zen_href_link(FILENAME_CATEGORIES, 'search=' . zen_output_string_protected($products_model)) . '" target="_blank">Click Here</a> to view the duplicates.</span>';
  echo $trigger_error;
  }
} 

[mc12345678]

Unless there is really something to be done within the first if statement, the newly added "feature" check could be rewritten as:

New update to prevent it from showing up on a product update

 // check for duplicates
$products_model = $_POST['products_model'];


$dups_query_raw = "SELECT products_model FROM " . TABLE_PRODUCTS . " WHERE products_model = :model ";
$dups_query_raw = $db->bindVars($dups_query_raw, ':model', $products_model, 'string');


$dups = $db->Execute($dups_query_raw);
if (!isset($_GET['pID']) && $dups->RecordCount() > 0) {
  $trigger_error = '<span style="color: red; font-size: 20pt; background-color: #FFFF00">
  Product Model number ' . zen_output_string_protected($products_model) . ' already exists ' . $dups->RecordCount() . ' times!
  <a href ="' . zen_href_link(FILENAME_CATEGORIES, 'search=' . zen_output_string_protected($products_model)) . '" target="_blank">Click Here</a> to view the duplicates.</span>';
  echo $trigger_error;
} 

And if the database has many items, executionwise it may actually be more beneficial to not execute the query until after the check of if the pID being set has been performed. So something like although in the below snippet really everything could be moved into the first if check unless there is something needed to be done with the data no matter whether the pID is set or not. But at least the below only tries to execute the query when the pID is not set:

 // check for duplicates
$products_model = $_POST['products_model'];


$dups_query_raw = "SELECT products_model FROM " . TABLE_PRODUCTS . " WHERE products_model = :model ";
$dups_query_raw = $db->bindVars($dups_query_raw, ':model', $products_model, 'string');


if (!isset($_GET['pID'])){
 $dups = $db->Execute($dups_query_raw);
 if ($dups->RecordCount() > 0) {
  $trigger_error = '<span style="color: red; font-size: 20pt; background-color: #FFFF00">
  Product Model number ' . zen_output_string_protected($products_model) . ' already exists ' . $dups->RecordCount() . ' times!
  <a href ="' . zen_href_link(FILENAME_CATEGORIES, 'search=' . zen_output_string_protected($products_model)) . '" target="_blank">Click Here</a> to view the duplicates.</span>';
  echo $trigger_error;
  }
}