previous unfixed component bug (with example)

[gabrielcrowe]

Here, you will find a product with broken attributes.

(please bear in mind tat while this popular item is broken, we lose sales, but iv left it broken, so that we can see this problem in action)

a problem i'v discussed before, and to be quite frank, has had people stumped before, and could not be fixed. This is actually a serious issue, and i'd like someone to look at it, with a perl mind, to help ME to fix it, since no one in actinic tech seems to be able to.

to help this along, i'v allready done/tried the following:

- refresh
- empty acatalog folder then upload
- compact database
- manually edit database

and up until now, the ONLY way to fix this, is to manually delete the entire component/attrib and all its choices, purge content and then re-build it from scratch.

we have thousands of products, this takes AAAGES.

select the last item from the dropdown list and try to add it to your cart. Broken.
Now, look here at my error.err, you can plainly see millions of these problems.

You see, (for the technical that are listening) for light users of these components/choices/attributes, that change rarely, there is no problem, so on a new catalog, its hard to maifest them, and therefore fix them. but as i'v pointed out previously, in a few other posts about this, its a problem for us, since we add and remove items from many attribs/choices DAILY.

his really shouldnt be a problem for actinic, its case of manipulating the database to remove the items right?

i'm willing to go the distance and sort this out myself, but i'm going to need some technical background on how the dropdowns work.

- how do they interact with the background perl?
- how does actinic edit the database when i edit the choices in an attribute?
- how can i detect the problems we have allready?

I understand that the error.err file is nonspecific, but an i add something to the perl to give me more debug information?

as you can tell, the degredation of our catalog and the effort required to repair it is getting serious. we spend approimately half our time now rebuilding these sections. its scary in fact.

please, can anyone help?

[gabrielcrowe]

*bump* *bump*

[cdicken]

Hi Gabriel

Here's an explanation of how components/attributes/permutations work in the database.

First of all, you are only dealing with one table - called 'ProductProperties'. It's the nType column that tells you what you are dealing with -

5 - Component
6 - Attribute
7 - Choice
8 - Permutation

There is also an 'sProductRef' column that tells you what product the item belongs to.

Each item has a unique nPropertyID value, and in the case of permutations, the nPropertyID of the relevant attributes and choices are used to create the permutation in the following format

[ID of attribute]:[ID of choice],[ID of attribute]:[ID of choice]

The other field to keep an eye on is nParentProperty, which tells you what attribute a choice is within and what component a permutation is within etc etc.

I hope this helps you diagnose what has gone wrong with your choices etc. when they go wrong, and maybe help you come up with an automated way to fix them.

[gabrielcrowe]

I hope this helps you diagnose what has gone wrong with your choices etc. when they go wrong, and maybe help you come up with an automated way to fix them.

I'm not taking the piss here honest, please dont take this the wrong way, I know you actinic people hava lot on your plates sometimes with us but...

that last comment was basically saying, that you either cannot, or will not try to find out how the problem is manifesting itself. As i have learned from playing around an awful lot, this problem has only started occuring since version 6 was upgraded to version 7. I feel that it is a problem in actinics source, in the manipulation of choices. Since this only occurs after a large amount of modifications, its fair to day that this problem wasnt originally picked up.

with this new information you've given me, i'll go all out to find a product that is broken, and then try my best to write something that fixes the damaged table. and i thank you for that information, but this is HIGHLY innapropriate.

consider me selling a complete skateboard and then telling the customer that we know that there is a problem with the bearings, but then we give them the width of a set of bearings that will fix the problem and expect them to mill the bearings themselves.

its a good job i'm a spectacular programmer, lest i'd never be able to fix silly problems like this.

all this aside, i do hope we can still be friends? DDDD

[cdicken]

OK fair point.

It wasn't meant to be a dismissive answer. The problem is that I am really limited in what I can help you with via the community - you need to work with a support technician who, in turn, will probably need to work with a member of the development team to figure out what is going on. Please register an email support query at http://www.actinic.co.uk/support/register.htm about this.

All anyone can give on the community is information - if you need anything more, you need to contact Actinic directly.

Hope that's cool.

[gabrielcrowe]

to let you all know. i'v managed to manually repair this problem. and i'm absolutely right about actinics source errors in its routines regarding the manipulation of its OWN database.

as chris has made me aware, we've taught ourselves how actinic builds its dropdowns and now have gained dufficient knowledge of it to be able to manually add and remove items.

opening the table, i'v found that actinic fails to update this table correctly.

please refer to attached 'problem1'. notice that this is a working table and uploads fine. we are looking at product 975, that is highlighted.

now, look at problem 2. after i use the actinic interface to delete then purge the top item. uk 13 junior from the list. uploading, causes a perl error. invalid attribute and component. actinic BROKE this table.

now, notice that the numbers dont tally up anymore. npropertyid no longer goes in increments of 1. and the product directly below, (which works fine) does not tally with the order of numbers that actinic has incorrectly given us.

check out problem 3. where i'v manually used access and edited it to what i think are the correct numbers. fixing the broken number sequence in npropertyid, and setting up the other cols similar to the item below.

i uplaoded, and it works.

its no problem chris. and i do hope we can arrange something. just gets me all revved up you see?

pass this data to your developers please?

thanks chris, for your help.

[cdicken]

OK - it looks like the bug might be that Actinic does not resequence the remaining choices after deleting a choice (i.e. it maybe should go back to 0,1 rather than staying as 1,2). I'll pass this on to the development team

[cdicken]

Also, the problem isn't with the PropertyID field - the missing number is because each choice has a unique ID - when you delete the choice, that ID is removed from the list.

[gabrielcrowe]

I got a reply from the support peeps. looks like they are looking into it.

after some experimentation, I think that perhaps the nPropertyID must be in a sequence? i say this becasue the perl backend does not like it otherwise.

Apparently, regardless of that, this problem does spill over into V8, after users with the problem allready in V7 upgrade.

i cant recall, but did V6 actually have 'permutations'? See, we dont actually use them. our dropdowns are pretty simple actually. we never have more than 2, and they they rarely ever change the price of the product. I tend to think that any sort of repair program i write would be quite complex, if permutations have to be involved.



for clarity, of the other features of this table to help me better understand, what is a '3' in the ntype field, and what exactly do the nValuex and bFlagx relate to in the actinic software?

[cdicken]

Hi Gabriel

You are right - if you are not using components, you don't need to think about permutations.

an nType of 3 is a custom property

With regards to nValue and bFlag, these are different for attributes and choices. bFlag isn't used for either.

Attributes:

nValue1
not used

nValue2
UI widget type
0 - Undefined
1 - Drop Down List
2 - Radio Button
3 - Check Box
4 – Button

nValue3
Property type – used for searching
1 - Text
2 - Integer
3 – Date

Choices:

nValue2
choice code – identifies the choice in a Permutation

[gabrielcrowe]

excellent.

i'm in the middle of writing an app that corrects the database. not only for v7, but for v8 sites that ahve had this problem carried forward. but i'm going to need more help with the way the table works.

this is what i'v learned and my app uses to correct the table so far, stop me if i'm wrong:

for every item (thats a 7) there is a matching container (6).

the 7 has an item 'nParentPropertyID' that matches the 'nPropertyID' of its parent 6.

the child 7's of a parent 6's nPropertyID value incriment by 1. if this is not the case, then it will break.
example:
1,2,3,4,5,6

the child 7's of a parent 6's 'nValue2value' incriment by 1, starting at 1. if this is not the case, then it will break.
example:
0,0,1,2,3,4,5

the child 7's of a parent 6's 'nSequence' incriment by 1, starting at 0. if this is not the case, then it will break.
example:
1,1,2,3,4,5,6

if these items are not met, then its not to spec? I'v noticed that those items in the table that are out of this spec WILL fail eventually, if added and deleted from sufficiently, but those that are corrected, last a little longer.

my app, uses these 'editable' rules to find the items that are broken, and then shows the ref. and name of the product thus far. no modifications to the table are allowed.

[cdicken]

for every item (thats a 7) there is a matching container (6).

If by 'item' you mean 'choice' and 'container' you mean 'attribute' then I am right with you.

I genuinely don't think you are right about the nPropertyID fields needing to be kept in sequence. They are just an arbitrary number assigned to each choice as you create it. They could be anything and it shouldn't have an effect. The sequence numbers are more likely to be the thing which causes the problem - and this is what I have reported to the team.

[gabrielcrowe]

this is very useful stuff.

sorry to blather on about this, but ther are just some things i need to know, else i'll thrash my tables, lol.

am i right in sying that over the entire table nPropertyID is a unique number for each record? or is it unique only in th confines of a particular selection?

i'v found over 400 errors in the this table alone, excluding the sync errors with nPropertyID. I'll code the rest of the app to rebuild the tables today, instead of just looking at them.

[gabrielcrowe]

also, after some more digging, that particular col. nPropertyID is a primary indexed without duplicates. so, its never going to be that really.

[gabrielcrowe]

A clunky solution

after some initial and sucessful testing, i'v cobbled together this... but be aware, it interacts directly with the actinic catalog. it MAY BREAK IT. so TAKE A BACKUP. This is a test, to see if this type of solution works for others. consider it a little beta.

all this app does, is seek out the items regarding product properties and resequence them so that the error 'invalid property' no longer occurs in the perl of the site.

- BACK UP your actiniccatalog.mdb
- The path is only for referfence and to change if your db is in a different location
- ONLY FOR V7. usage on V8 will butcher the database.
- BACK UP your actiniccatalog.mdb
- BACK UP your actiniccatalog.mdb NOW.
- Close actinic before you run this app.
- WE DONT USE PERMUTATIONS so i have no idea how this will break/fix yours

As chris suggested, there was no need to resequence the property nPropertyID so its left untouched. but 'nValue2' and 'nsequence' are reset to what i think are the correct values. For me, this fixed 400 odd products, making over 100 purchasable again. we were losing money.

Pretty simple stuff:
1: close actinic
2: open the app
3: ensure that your database lies at the path shown
4: press the button
5: wait till its done
6: close the app.
7: open actinic and upload.

feedback please. does it work for you? did it mangle your database?
gabriel at skateasylum.co.uk

remember: BACK UP YOU DB.