Printable View
I think someone else commented out the line(s) that made the call. My understanding for the reason that is used is to ensure/force all data to be UTF-8 encoded. Been a while since I have looked at that area, but it made sense to me and I didn't want to modify what worked, especially if it is/was on my side that was not setup to handle the calls made.Quote:
Originally Posted by countrycharm
That information shows when I pull up my server info. No I'm not getting anymore error messages for some reason. All I'm getting is well you knowQuote:
Originally Posted by mc12345678
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Go figure, now all the sudden it started working. Strange stuff ...... :)Quote:
Originally Posted by countrycharm
That's correct, my entry was products_id on that field, nothing else was touched.Quote:
So, for the first thing, am I correct you entered just: products_id in the User defined fields entry of the configuration->Easy Populate 4. Not v_products_id. The code will export a products field that is provided in that user defined fields entry.
So something is wrong with that setup (not the program)
Not correct. All the items started by 001- (I really don't understand why he did that, but I'm sure if there's any other way for him to create models it will be ok, since he's only using them to use EP, nothing else.Quote:
3. So, you do not have any products that have a model number that starts with 001- correct?
Okay, thank you for clarifying. I'll create something that uses a different prefix but will include the product I'd.Quote:
Originally Posted by ideasgirl
Odd, that the products_id did not export because it is designed to do so if included as a custom user field. Will look to see if there is code to prevent it's export, which I would consider unusual when the field is specifically a custom field. Understandable when/if used internally..
It should export as v_products_id if it did get exported.
Okay, so below is a SQL statement that when used through the ZC Install SQL Patches area will update all blank model numbers to start with the string provided in the first part of the concat function (in this case 002-). Now, it hasn't been written to prefix zeros so that second part of the model number is a uniform length. That's a separate thing to address.Quote:
Originally Posted by ideasgirl
The end of that string is two apostrophes not a single quote.Code:
UPDATE products SET products_model=concat('002-', products_id) WHERE products_model='';
If the above is run through mySQLAdmin, then the table prefix would need to be added to the 'products' statement.
For those reading this in the future. The prefix 002- was chosen because no other existing model # began with 002- and therefore no duplication would result.
Great! Is there any reason as to why not use 001- ?
If the store owner mapped 001- as consecutive entries instead of in accordance with the product_id (or if mistyped when entering it by product_id) then the possibility of duplication may exist and then, well all sorts of unexpected things start happening if the duplication was not planned.Quote:
Originally Posted by ideasgirl
If you find that you would have no problem with the data if it is prepended with 001- then feel free to change it. Also, there are ways to force formatting with 0's prepended to the products_id, but also if the model # is only being used for EP4, then there really isn't a need to do that. (Ie., not displayed with the product(s), not used for any sort of tracking, etc...).
It's all in planning and future use. Later, a similar SQL update query could be run to modify/replace the '002-'s with 001-, but I am trying to provide a generic resolution that is knowingly guaranteed not to cause an immediate problem. :)
Yes, it was consecutive entries on the spreadsheet (nothing to do with product_id).Quote:
If the store owner mapped 001- as consecutive entries instead of in accordance with the product_id (or if mistyped when entering it by product_id) then the possibility of duplication may exist and then, well all sorts of unexpected things start happening if the duplication was not planned.
I already ran it with both 001, and 002, didn't see anything unusual the only odd thing that on products all display if i sorted by model number for example 001-101, then 001-1001, 001-1019, 001-102, 001-1020... that kind of sorting, but it will do the same in both scenarios.
I will use 002 just to be safe.
I couldn't edit my post to include the screenshot I forgot to include:
http://imageshack.com/a/img823/9546/llna.jpg