EasyPopulate 4.0 Support Thread

Recommendations on how to get a sample file?

outeredge2:

Recommendations on how to get a sample file?

I always love this question.

Export something from your database. :) no better sample than what comes out. :)

I am using version Easy Populate 4.0.32 - Beta 12-30-2015. Where does CURRENT_TIMESTAMP get it's value from ? When I leave the v_date_added field blank the product shows "This product was added to our catalog on Tuesday 30 November, 1999." If I export the products in Easy Pop I see 0000-00-00 00:00:00 in v_date_added
Henry

henry3:

I am using version Easy Populate 4.0.32 - Beta 12-30-2015. Where does CURRENT_TIMESTAMP get it's value from ? When I leave the v_date_added field blank the product shows "This product was added to our catalog on Tuesday 30 November, 1999." If I export the products in Easy Pop I see 0000-00-00 00:00:00 in v_date_added
Henry

Well, blank is 0, if wanted. Now. As the value that would/should be supported though it may not now be supported because of the rewrite to use bindVars, I'll have to take a look. The other factor to consider though is in fact how to handle having the date field in the file with a blank entry. Btw, what php version is being used in this situation?

Also, although both need to be addressed, was this an insert or an update?

It was on importing a new product. PHP ver 5.5. I would assume if the date is blank in the import file it should default to current date, which is what the code appears to be doing. I assume CURRENT_TIMESTAMP was a Zen Cart global at one time ?
Henry

henry3:

It was on importing a new product. PHP ver 5.5. I would assume if the date is blank in the import file it should default to current date, which is what the code appears to be doing. I assume CURRENT_TIMESTAMP was a Zen Cart global at one time ?
Henry

CURRENT_TMESTAMP actually is a mysql constant. One problem though is that because the field is present, the value of the field overrides the "internally" generated possible value. The other issue is that a "blank" date time should be 0001-01-01 ish. Not all 0's. That was corrected for a different condition elsewhere but not this one.

It's also odd if I put a value 2016-03-01 09:00:00 in v_date_added, it doesn't show up, but the same value in v_date_avail works correctly. If both values are filled, the v_date_avail doesn't import either.

henry3:

It's also odd if I put a value 2016-03-01 09:00:00 in v_date_added, it doesn't show up, but the same value in v_date_avail works correctly. If both values are filled, the v_date_avail doesn't import either.

Well a date avail in the past even in a product info page acts "oddly" but when reviewing the history it makes sense... The field is intended to prevent the product from being displayed until the date available has passed then it "clears" the field. I forget if it wipes it or sets it to 0001-01-01 or not. As to the "proper" usage of the populating a date I'll take a look. Was this again an insert evolution or an update? Also, is it sure that the entry hasn't caused or is associated with having a linked product? I'll be ndependently testing either way, but might explain some of what is/was seen.

I was importing new products on my development site. The work around is just to put the current date in v_date_avail and leave v_date_added blank

henry3:

I was importing new products on my development site. The work around is just to put the current date in v_date_available

Ahem... What about the more obvious, don't include the current date field?

If I leave both date fields blank on import the product page shows "This product was added to our catalog on Tuesday 30 November, 1999." The table shows products_date_added 0000-00-00 00:00:00 products_last_modified 2016-03-02 18:53:47 products_date_available 0000-00-00 00:00:00

henry3:

If I leave both date fields blank on import the product page shows "This product was added to our catalog on Tuesday 30 November, 1999." The table shows products_date_added 0000-00-00 00:00:00 products_last_modified 2016-03-02 18:53:47 products_date_available 0000-00-00 00:00:00

I didn't say leave the row blank, I said completely don't include the field. The entire column. No column, no data from the spreadsheet to do anything with, default coding takes over...

I deleted both date columns,made a new record, and date added and available still show in the database as all zeros

henry3:

I deleted both date columns,made a new record, and date added and available still show in the database as all zeros

I believe 4.0.32 has been fixed... A combination of things between using bindVars to generate a string (adds quotes around text) when instead it was occasionally desired for it to not have quotes, blank data in some cases was allowed to be all 0's instead of the ZC "empty date", etc.. The few lines needing to be corrected in the import file have been adjusted... To obtain the specific changes, can goto: https://github.com/mc12345678/EasyPopulate-4.0/commit/834d09d85a8974f1b57dae7d3913db201c774f5f

I think this was happening to me too. But my situation is a little different cause I'm making changes as you know, so I haven't payed much attention to that, because It's another product type, and didn't know what was doing what.

I actually posted my doubts in bookx thread in #post1304799

But then for some reason things start working, but I read this and looking now at some exports files all I got 0000 too. So I didn't quite understood if this was happening on admin product insert, or in the imports / exports.

As I said, just saying that I've seen this, but it's not very relevant has I'm messing around with ep4 ad database a lot, and haven't tested only this field.

I believe when importing the products ordered qty's are being reset to zero. I used this module a couple months back to import some custom fields and just noticed these were reset and I did not reset them. T compared to a backup from before I did the import and the only different between my active database file and the backup are the fields I imported.

mesnitu:

I think this was happening to me too. But my situation is a little different cause I'm making changes as you know, so I haven't payed much attention to that, because It's another product type, and didn't know what was doing what.

I actually posted my doubts in bookx thread in #post1304799

But then for some reason things start working, but I read this and looking now at some exports files all I got 0000 too. So I didn't quite understood if this was happening on admin product insert, or in the imports / exports.

As I said, just saying that I've seen this, but it's not very relevant has I'm messing around with ep4 ad database a lot, and haven't tested only this field.

Nope it was a real thing resulting from the switch to using bindVars and not properly incorporating the "alternative" data 1) the constant was being turned into a text statement rather than presented as a sql constant, 2) 0 was entered as the date entered instead of the ZC 0001-01-01 which was a condition of this software from original development. Both situations ought to now be addressed in 4.0.32 or by applying the patch referenced above.

marcopolo:

I believe when importing the products ordered qty's are being reset to zero. I used this module a couple months back to import some custom fields and just noticed these were reset and I did not reset them. T compared to a backup from before I did the import and the only different between my active database file and the backup are the fields I imported.

Not sure I understand the results that are being described. Ordered quantities as tracked by default ZC are in no way touched or addressed by this plugin. That data is collected from the orders table and there is currently no facility to write to that table or any related table.

Now on issues with user defined fields, I was going to look at how the code responds if the user defined field is present, but the field is not identified in the import file just to validate that the row data for that field is not modified, but there is no control if the field is present in the import file and the user has decided to leave the field blank. In that situation the code would work as expected by updating the record to be blank as it is/was in the import file.

So, could use a little more clarification of the perceived issue in order to provide a solution either by code or direction.

I'm using Easy Populate 4.0.30 - Beta 06-27-2015

I define the following fields in admin setting in Easy Populate:
User Defined Products Fields: products_ordered,products_length,products_width,products_height,products_ready_to_ship

I exported Complete Products (with Metatags) then removed all but either id or model forgot which is required and the defined above and imported back with the defined fields populated as I needed them to be. That's all I did which I believe reset the quantity ordered as I described.

marcopolo:

I'm using Easy Populate 4.0.30 - Beta 06-27-2015

I define the following fields in admin setting in Easy Populate:
User Defined Products Fields: products_ordered,products_length,products_width,products_height,products_ready_to_ship

I exported Complete Products (with Metatags) then removed all but either id or model forgot which is required and the defined above and imported back with the defined fields populated as I needed them to be. That's all I did which I believe reset the quantity ordered as I described.

[So, here is what I understand in “date” order and therefore remain perplexed if there is an issue or not:
At point A a backup of the database was made.

At point B an export was made, the file modified to only include the primary reference key and user defined fields that were to be updated with whatever was in the import file.

At point C, the import file with the primary key and user defined data fields was imported causing the product identified by the primary key to be updated with whatever was present (or “absent”) in the user defined fields. The data for each field had been updated as desired/requested and all fields were present in the file. This included a field called products_ordered.

At point D (call it today), a comparison of the live database to the backup made at point A shows that everything is the same except for the data that was stored at point C. But the data in the products_ordered field is now zero instead of the quantity identified in the file at point C.

So question(s) are:

1. Did the import file at point C actually include the products_ordered field or not?
   1.a) If it did, how do the values identified there relate to what is/was in the database?
2. If you were to again upload just a single row of data that included the products_ordered field and information for that field, what happens to the information of that product and field?
3. When uploading are the user defined fields still present even when the involved import file doesn't have data for the applicable field?