internal error - [attribute[ has lists

[rocketman]

One of my lists suddenly developed a problem after working fine for some time. although it showed 74 entries in the list, I couldn't get it to page after number 60 - the list came up blank.

It's a transactions BO which contains a shortcut to an attribute in Chart of Accounts BO called acc_Name

I then went to delete all the transaction and got an error saying that the attribute in the linked BO (ie the Chart of accounts) contained lists.

The only thing I can see is a few of the CofA names contain a / character (as in Under21/Student membership)

As part of the test process I recently renewed a Junior member so one of the very recent additions to the transaction list will be an entry with a shortcut to an attribute that reads Under21/Student

Could this be causing the problem or do I need to look deeper for the problem

[ACDC]

Somewhere along the line there is a shortcut in your app that relates to a reference where multiple is allowed ( as you know shortcuts can only relate to single references).

I experienced this problem once before and found that the problem had been lurking for sometime and only became evident under a certain set of events . So the problem could have been created sometime back when you made some changes to the object.

some clues that could have led to this :

1. an attribute was edited and the Multiple status could have been evoked after the setup of the shortcut
2. The attribute is grouped with other objects (BO groups) and one of the attributes in the group is set to multiple (or was set to mutiple.)
3.The shortcut, that no longer should be a shortcut as a result of its change to multiple, is still checked in the reference attribute setup
4.Renaming or changing the properties of an attribute that's associated to a shortcut


This problem had me going in circles and pulling my hair out, I eventually resolved things by deleting shortcuts and recreating them.

good luck

[rocketman]

Thanks ACDC, deleting the shortcut didn't help but deleting and then re-instating the reference field (in both BO's did the trick as far as new transactions are concerned. However I noticed that transactions that were already in the system were no longer linked to their Chart of Accounts BO

That kind of fills me with dread because I assume that when I publish, the same thing is going to happen with the live transactions, I am assuming (hoping) the followingh will work

1) export the transactions references
2) export the CofA references,
3) Publish the revised version
4) Import the references

Do you have a view on this -

[ACDC]

Its okay to delete shortcuts, but deleting references are going to get you into trouble

I think if you had renamed the reference instead of deleting, it would have done the trick, but now you will have to relink as you have suggested - this should work - just make sure u have both backups in place i.e. the Database and the AwareIM directory

By the way, it might be a good idea to run an integrity check on the related objects before you do the fix. I normally do this with a process UPDATE BO etc etc. and monitor the log while running the process.This will force the rules to fire and uncover anything else that may be lurking

I try and maintain strict disciplines when it comes to editing existing attributes, especially when there are shortcuts involved. The configurator is definitely not bullet proof, it has its quirks and its very easy in a moment of haste to do something that gets through the integrity check.

Personally I think there should be more integrity checking in the configurator when editing attributes, but the system already does an excellent job at everything else

[nlarson]

Hi, I have this issue currently. At one point I had considered doing a many-to many on a new feature, but thought the better of it and move the Reference back to many-to-1. The shortcut in question points to the 1, not the many so I don't see the problem, except for some type of corruption.

Here is what I did so far:

1. I deleted the shortcut and saved
2. then set the Ref back to allow multiple
3. Saved and Published
4. Created a new version and set the ref back to single (which I thought would delete the bad data)
5. Added the short cut back in
6. Published
7. Still happened so did the same, but deleted the ref and pasted from a working version

I still have the issue, so I think maybe it is data related? Can I safely DELETE from the _ref table? Any other suggestions?

Worst case I can delete and re-create from scratch, but having tried to approximate that in item 7 I belive I would need to publish in between the delete and recreate to clear the previous column in the DB, and that would be a bit of a PITA due to query and rule dependencies.

[nlarson]

deleting the data resolved the issue.

[RLJB]

We had this error on one of our apps.

Our issue was a process was being run that did an insert to an ref attribute that wasn't "multiple allowed" - deleting the instance solved the issue (so it is a data issue).

In our case it was two Customer Orders being inserted into One invoice (when only 1 was allowed) - deleting one of the Customer Orders fixed it.

[joben]

Bumping this thread to provide an alternative solution in case you get the "contains lists" error and don't want to rebuild the shortcut or delete all data.
In a recent scenario I had a relationship and a shortcut set up that would throw this error when viewing certain items in a form, or even displaying them in a query.

What I did, and what you could do is running this SQL query to look for duplicates in the BO reference table:

Code: Select all

SELECT RID, COUNT(*) AS Count
FROM cars_ref
GROUP BY RID
HAVING COUNT(*) > 1;

If you do get results like...:

Code: Select all

RID	Count
4567	2

...then you need to delete the duplicate(s) so that only one record can have the same RID.

Code: Select all

SELECT * FROM cars_ref WHERE RID=4567;

Delete one of the rows and the error will disappear.

Note: In my case, the reason for this error was 100% my own fault for tampering with the SQL tables by restoring some old data via SQL. This is why some duplicates were restored by mistake.