Database I/O Manager (DbIo) Plugin [Support Thread]

So, to clarify for the dummies, for an import,

new product
v_categories_name: can be a list. The first path will be the master category. Subsequent paths will be added as linked categories.

existing product
v_categories_name: can be a list. Paths will be added as linked categories, if not already existing for this product.

existing product & using UNLINK command
v_categories_name: can be a list. Paths will be removed only if they are linked categories.

So, to update existing products, it is necessary to export them to get the list of linked categories, to be able to subsequently import and UNLINK them.

torvista:

So, to clarify for the dummies, for an import,

new product
v_categories_name: can be a list. The first path will be the master category. Subsequent paths will be added as linked categories.

existing product
v_categories_name: can be a list. Paths will be added as linked categories, if not already existing for this product.

existing product & using UNLINK command
v_categories_name: can be a list. Paths will be removed only if they are linked categories.

So, to update existing products, it is necessary to export them to get the list of linked categories, to be able to subsequently import and UNLINK them.
Close ...

new product
v_categories_name **must **be specified (otherwise, you don't know where it goes in the category tree). The last/most-recent v_categories_name imported for a product will be its master-category; previous categories will be linked categories.

existing product
v_categories_name, if specified, identifies the current master-category for the product. Previous categories become linked categories.

existing product & using UNLINK command
v_categories_name **must **be specified. The category-path will be removed if-and-only-if it is not the product's master-category (an error is indicated if so).

Getting that linked-categories list is going to be a PITA, as the Products-export exports *only *the product's master-category's name, not the additional linked ones. I'll put such an export on the DbIo to-do list.

I'm afraid I don't find that very intuitive.
I would have thought the first category in any list would be master, the rest....would just be the rest/linked.
And so an export of categories in the products export would include that list.

An import of the products with that column missing would be no change.
An import of the products with that column would update (delete+add), same as the other fields.

The idea of whatever being in the list adding to whatever is already in the db, I find confusing / an unexpected thing and out of step with every other column, in the sense that all the rest will replace the current entry.

Maybe I am used to Apsona doing that....

torvista:

I'm afraid I don't find that very intuitive.
I would have thought the first category in any list would be master, the rest....would just be the rest/linked.
And so an export of categories in the products export would include that list.

An import of the products with that column missing would be no change.
An import of the products with that column would update (delete+add), same as the other fields.

The idea of whatever being in the list adding to whatever is already in the db, I find confusing / an unexpected thing and out of step with every other column, in the sense that all the rest will replace the current entry.

Maybe I am used to Apsona doing that....
Sorry that it's not intuitive ... at least it's documented now!

FWIW, the 'last-in' usage model is similar to the non-Image Handler way of uploading additional images. You edit a product, uploading first those additional images and upload the product's main image as the last step.

FWIW, the 'last-in' usage model is similar to the non-Image Handler way of uploading additional images. You edit a product, uploading first those additional images and upload the product's main image as the last step.
Really...never done that! Always used IH.

Hi,

In an old modified version of easypopulate I could import and export all product info and products quantity discounts in one CSV. In a brief look at dbio I don’t think it can do that. If not is it possible to modify dbio to achieve that? I guess otherwise I’d need to upload two CSVs every time there is a product price change.

RETPL:

Hi,

In an old modified version of easypopulate I could import and export all product info and products quantity discounts in one CSV. In a brief look at dbio I don’t think it can do that. If not is it possible to modify dbio to achieve that? I guess otherwise I’d need to upload two CSVs every time there is a product price change.
DbIo currently has the products' quantity discounts, as you indicated, as a separate "handler" from the other products' fields. While anything is possible, code-wise, that quantity-discounts' handling is a bit special and the products' handling is already complicated so I don't think that I'll be combining them.

I guess you're looking at two CSVs when products' pricing changes.

Can't you use one file for all your manipulation (I use Libreofice), with all the column titles as used in both handlers, then save-a-copy two csv files with different names to use the correct handler. Each handler should ignore the columns that are not part of that handler.
Then you are not having to work with two files.

torvista:

Can't you use one file for all your manipulation (I use Libreofice), with all the column titles as used in both handlers, then save-a-copy two csv files with different names to use the correct handler. Each handler should ignore the columns that are not part of that handler.
Then you are not having to work with two files.
You're always thinking, @torvista. That's a great idea.

I've just submitted v1.6.4 of DbIo for the Zen Cart moderators' review; I'll post back here when it's available for download.

 This release contains changes associated with the following GitHub issues:

#175: Correct CSV 'split' function processing.
#176: 'Products': Multi-lingual customized-template export columns can 'go off'.
#177: No admin message when multiple v_dbio_command columns are found.
#178: 'Products' import, enable a product to be 'unlinked' from a linked category.
#179: Valid dates that don't start with a year are being indicated as invalid.
#180: Additional configuration setting for Products to require an 'ADD' command to insert a new product.
#181: ProductsAttribsRaw: Unwanted download record added for empty download name.

lat9:

I've just submitted v1.6.4 of DbIo for the Zen Cart moderators' review; I'll post back here when it's available for download.

 This release contains changes associated with the following GitHub issues:

#175: Correct CSV 'split' function processing.
#176: 'Products': Multi-lingual customized-template export columns can 'go off'.
#177: No admin message when multiple v_dbio_command columns are found.
#178: 'Products' import, enable a product to be 'unlinked' from a linked category.
#179: Valid dates that don't start with a year are being indicated as invalid.
#180: Additional configuration setting for Products to require an 'ADD' command to insert a new product.
#181: ProductsAttribsRaw: Unwanted download record added for empty download name.
Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2091

Hi Cindy

A user says

The 'DBIO Split File: Record Count' is being ignored. It is set at 60000 which usually produces 6 files, it is currently producing 22!

I have had him confirm that the file itself is correct and not malformed (ie. it's not suddenly over 3 times larger than before), but although he's set it to split at 60000 records per file, it is splitting to around 3000 records per file.

Can you offer any suggestions as to why this might be?

Ryk:

Hi Cindy

A user says

I have had him confirm that the file itself is correct and not malformed (ie. it's not suddenly over 3 times larger than before), but although he's set it to split at 60000 records per file, it is splitting to around 3000 records per file.

Can you offer any suggestions as to why this might be?
Is the user, perhaps, using a version of DbIo prior to v1.6.4? There were corrections for the 'Split' processing in that version.

Thanks - looks like he's still on 1.6.3 - will try the upgrade

I've tried to find my answer because I'm sure it's here but I cannot find it.

My client is/was using Apsona (which no longer works for us) and needs to add products. I'm getting:

✗ products.products_id, line #2: Value () is not an integer

DBIO 1.6.3
ZC 1.536c

I have ADD in v_dbio_command and v_products_id is blank.

What formatting do I need to insert new products?

jeking:

I've tried to find my answer because I'm sure it's here but I cannot find it.

My client is/was using Apsona (which no longer works for us) and needs to add products. I'm getting:

✗ products.products_id, line #2: Value () is not an integer

DBIO 1.6.3
ZC 1.536c

I have ADD in v_dbio_command and v_products_id is blank.

What formatting do I need to insert new products?
You can simply set the v_products_id field to **0 **(not an empty string).

lat9:

You can simply set the v_products_id field to **0 **(not an empty string).

To an old Staples add, "that was easy". THanks!

jeking:

To an old Staples add, "that was easy". THanks!
Easy is good!

I'm having a small issue that's driving me crazy, I'm using dbio to bring products onto a new Zencart site. However, when uploading new products with a specific ID i would like to keep it seems that dbio is ignoring v_products_id and instead using a generated auto-increment value.

I have looked through the settings and don't believe this is something that can be controlled?

Feel like I'm missing something obvious...

DannyVarley:

I'm having a small issue that's driving me crazy, I'm using dbio to bring products onto a new Zencart site. However, when uploading new products with a specific ID i would like to keep it seems that dbio is ignoring v_products_id and instead using a generated auto-increment value.

I have looked through the settings and don't believe this is something that can be controlled?

Feel like I'm missing something obvious...
You're not missing anything obvious (I'll update the documentation to make it more clear).

If a products_id isn't already present in the database for a ***Products ***import, then it's a *new *product and, to keep the database integrity, a new auto-increment value is assigned. The same holds true for any import: If the auto-incremented 'id' for the to-be-imported table doesn't already exist, the next auto-increment value is assigned on the import.