Content Database...Products getting deleted

NorthOf45

pfunkyfize said:

NorthOf45 said:

Have you looked in product LOCAL USER to see if your files are there? When installing a product that has no metadata support files, DIM or Studio creates a minimal metadata file with entries for each item (Assets or SupportAssets), even old Poser files, and zips created with Content Package Assist (if there is no metadata file included), so they should not end up in LOCAL USER.

So does the act of taking a product in zip format from a brokerage like Renderosity and manually unzipping it into my content library (aka -not going through DIM ) somehow makes an association to the LOCAL USER product? Does Studio's install procedures do this?

This is what is commonly referred to as Manual Installation, and isn't really "installed", as Studio sees it, the items just appear in the Library the next time you start Studio, or refresh the Library. There will be no metadata for it, no Product name, no Product token, no Assets, nothing, so CMS sticks it in LOCAL USER by default. (If you create a new preset or scene, it ends up in LOCAL USER, because it is not part of any product). Then you get into the whole creating products and metadata scenario, if you want it. Installing with DIM will get you something to start with, at least, but the product has to first be re-packaged for DIM (i.e., with Content Package Assist).

pfunkyfize

NorthOf45 said:

pfunkyfize said:

So does the act of taking a product in zip format from a brokerage like Renderosity and manually unzipping it into my content library (aka -not going through DIM ) somehow makes an association to the LOCAL USER product? Does Studio's install procedures do this?

This is what is commonly referred to as Manual Installation, and isn't really "installed", as Studio sees it, the items just appear in the Library the next time you start Studio, or refresh the Library. There will be no metadata for it, no Product name, no Product token, no Assets, nothing, so CMS sticks it in LOCAL USER by default. (If you create a new preset or scene, it ends up in LOCAL USER, because it is not part of any product). Then you get into the whole creating products and metadata scenario, if you want it. Installing with DIM will get you something to start with, at least, but the product has to first be re-packaged for DIM (i.e., with Content Package Assist).

I didn't know that's how assets get thrown into LOCAL USER. Very interesting, I've been using CPA for some time now so that I could get product names to show up in the Content Library that I knew but i didn't know manual installs added to that catch all product.

NorthOf45

pfunkyfize said:

NorthOf45 said:

pfunkyfize said:

So does the act of taking a product in zip format from a brokerage like Renderosity and manually unzipping it into my content library (aka -not going through DIM ) somehow makes an association to the LOCAL USER product? Does Studio's install procedures do this?

This is what is commonly referred to as Manual Installation, and isn't really "installed", as Studio sees it, the items just appear in the Library the next time you start Studio, or refresh the Library. There will be no metadata for it, no Product name, no Product token, no Assets, nothing, so CMS sticks it in LOCAL USER by default. (If you create a new preset or scene, it ends up in LOCAL USER, because it is not part of any product). Then you get into the whole creating products and metadata scenario, if you want it. Installing with DIM will get you something to start with, at least, but the product has to first be re-packaged for DIM (i.e., with Content Package Assist).

I didn't know that's how assets get thrown into LOCAL USER. Very interesting, I've been using CPA for some time now so that I could get product names to show up in the Content Library that I knew but i didn't know manual installs added to that catch all product.

A trick I learned about packaging third-party products is that once you have made the DIM and installed it, filled in any metadata you want to add (content type, compatibility or compatibility base, etc.) you can export it to the .dsx file (only from the Edit Metadata in the Product view) and add it back into the CPA project and build an updated version. That way it will get installed with the product via DIM in case you need to re-install it, and you get all your metadata back without having to restore User Data.

pfunkyfize

NorthOf45 said:

A trick I learned about packaging third-party products is that once you have made the DIM and installed it, filled in any metadata you want to add (content type, compatibility or compatibility base, etc.) you can export it to the .dsx file (only from the Edit Metadata in the Product view) and add it back into the CPA project and build an updated version. That way it will get installed with the product via DIM in case you need to re-install it, and you get all your metadata back without having to restore User Data.

That method is something similar to the way when I create new products. I'll develop something in a staging set of content libraries, once it passes and can be promoted to production, I'll wrap it up in a custom DIM zip and install it. I then make metadata for any smart content etc and then repackage the item with those updated DSX files. I may have to start doing that with other brokerage items. I didn't do it with places like Rendo because i figured I would just add meta after I have used it for awhile. However, the only rhyme so far is that all my non-DAZ products I have installed with CPA no longer have assets inside their product entries. I think the next logical step is finding an automated way via script or SQL to sift through 49,000 assets in LOCAL USER and remove the reference there.

Editing metadata would be a snap if the Database administration tool that comes with Postgresql (which is also provided with Studio/Postgresql so it's not a hack method, SQL is a common software tool for business industry databases) was working and would allow me to see all the tables where our product data is kept and I could edit them direcly with 1 line of SQL code as opposed to multiple function calls with DAZscript like in their examples. I submitted a tech support ticket for that issue...

pfunkyfize

Another reason to be able to use the RDBMS of PostgreSQL instead of the metadata editor is that Studio locks up/crashes anytime I try to edit metadata on the LOCAL USER product... That forces a user to make changes to the Database records via script or SQL since the metadata editor freezes up...

pfunkyfize

The way to open the database for SQL usage has been discovered and I am a happy man! I can see all my products and assets that are assigned to LOCAL USER through a simple SQL query and because I am using SQL to do it, I can update destroyed records with the correct entries all in one fell swoop. Without having to do things a chunk at a time or onesy-twosy method which will ultimately drive me insane after 10-15 minutes.

The implications are also awesome because I can use Perl/Python/Java/PHP or whatever programming language i like to manipulate/view my product metadata because they have PostgreSQL application interfaces. So that means I wouldn't even have to open DAZ or DIM to edit metadata in the CMS database. I like this very much...

Chatjd

I've found through trial and error with reimporting metadata that having a forward slash between the quote and runtime in the Asset line won't work except when DIM installs it the first time.  You need to take that forward slash out on all the Asset Value lines (not the support asset lines, just the Asset Value lines)

<Asset VALUE="/Runtime/

needs to be:

<Asset VALUE="Runtime/

pfunkyfize

Chatjd said:

I've found through trial and error with reimporting metadata that having a forward slash between the quote and runtime in the Asset line won't work except when DIM installs it the first time.  You need to take that forward slash out on all the Asset Value lines (not the support asset lines, just the Asset Value lines)

<Asset VALUE="/Runtime/

needs to be:

<Asset VALUE="Runtime/

Wonderful! That's a land mine I won't have to step on now, thanks SQL code warrior!

pfunkyfize

So far I've found that the records in the Product and Content tables are missing from the products that are empty in my Content Library tab. Also found that -10 is the id for the LOCAL USER product so i can see all my products from DAZ and stuff I've loaded from Renderosity that have somehow made its way to LOCAL USER product. I'm getting the feeling that the Content and Product tables are the master tables with content being the child table because of the foreign key constraints in the CREATE table for Content. There is a tblContent and tblProduct table that I need to figure out their relationship to the master Content and Product table because there are no foreign key constraints containing references to the tblContent and tblProduct tables. I suspect the triggers and stored procedures will give me hints on their usage...

pfunkyfize

Chatjd said:

I've found through trial and error with reimporting metadata that having a forward slash between the quote and runtime in the Asset line won't work except when DIM installs it the first time.  You need to take that forward slash out on all the Asset Value lines (not the support asset lines, just the Asset Value lines)

<Asset VALUE="/Runtime/

needs to be:

<Asset VALUE="Runtime/

Let me step back and ask this,

When you say reimporting metadata into the DB, are you doing it through the database maintenance tool in DAZ? I am trying to avoid that and want to reimport data via SQL outside of DAZ/DIM and not open either app at all.. My code will look like a bunch of INSERT and UPDATE DML statements. Currently I am looking inside the database to see what tables are getting populated when a custom DIM .zip archive gets placed into the database. Once I figure that out I won't need DSX files to load metadata into the database.