Key Already Used In Dictionary

[M45HY]

Hi guys,

I’m coming across with a slight problem whenever I try to write to a dataset using a data dictionary. I spoke to one of my fellow colleagues and he stated that the reason why this error is occurring is because the system believes it’s trying to create a duplicate record. I checked the data that was going to be entered and it is different but this error occurs before the differences are met; causing the error.

Any clues anyone?

Omash

[ghosttie]

Can you post the code?

[BeeJay]

From your comment "it is different but this error occurs before the differences are met" I'll make an assumption that this collection is the other side of an automatically maintained inverse and you are setting this side of the inverse before you have set all the properties that are used as the keys on the MKD inverse. If this assumption is correct, then you should move the setting of this side of the inverse until after you have set the values of all the properties used as the keys on the MKD. This will also have the added advantage of avoiding all the additional automatic inverse maintenance that will be occurring.

For example, suppose you have two properties called string1 and string2 on class C1 that are used as the dictionary keys on a collection allC1s on class C2 that is inversed to the myC2 property on class C1. Now consider the following code where our c2 variable is already referencing the desired instance of class C2:

Code: Select all

create c1; c1.myC2 := c2; // Automatic inverse maintenance will add "null, null" key entry to allC1s collection c1.string1 := "Hello" // Automatic inverse maintenance will remove the "null, null" key entry and add "Hello, null" key entry to allC1s collection c1.string2 := "World" // Automatic inverse maintenance will remove the "Hello, null" key entry and add "Hello, World" key entry to allC1s collection

This could result in a duplicate key is there's already a "null, null" or a "Hello, null" key entry in the collection, even though it would eventually not match based on all the property values.

You can avoid the duplicate key exception, and avoid the multiple automatic inverse maintenance, by simply deferring the setting of the myC2 reference until after the properties used as keys have been set as follows:

Code: Select all

create c1; c1.string1 := "Hello" // No automatic inverse maintenance yet as myC2 is still null c1.string2 := "World" // No automatic inverse maintenance yet as myC2 is still null c1.myC2 := c2; // Automatic inverse maintenance will add "Hello, World" key entry to allC1s collection

Hope that helps.

Cheers,
BeeJay.

[M45HY]

Hi guys,

First and foremost, thank you for the quick response.

@ghosttie : Hey ghosttie; I'm not sure if I can post word-for-word but if you imagine that there is an example dataset called BASKET and it stores the data Emp, Item, Amount and Date so we have Emp 1 with Item 1 with Amount 5.00 and a null date and then I try writing Emp 1, Item 1 with Amount 6.50 and date as 20/09/2013 (using a DynaDictionary), the system will throw the error as Emp and Item are the keys and it thinks that I'm about to duplicate a Key. BeeJay's example is a good example.

@BeeJay : Hey BeeJay, so according to the example above, if I was to write to the dataset in the order Amount 6.50, Date 20/09/2013 followed by the Emp and the Item, would this avoid me getting the "Key Already Used In Dictionary" error message?

Thanks guys,
Omash

[BeeJay]

@BeeJay : Hey BeeJay, so according to the example above, if I was to write to the dataset in the order Amount 6.50, Date 20/09/2013 followed by the Emp and the Item, would this avoid me getting the "Key Already Used In Dictionary" error message?

No. If your keys consist only of Emp and Item it doesn't matter what order you set the properties you'll get a duplicate key error when adding the 2nd instace of BASKET to your DynaDict as the 2nd instance of BASKET has the same key values as the first instance. It doesn't matter in the slightest that there are other properties with different values on the instances of BASKET as those properties are not used as keys in your DynaDict.

You have two options available to you:

1. Turn on duplicates allowed on the DynaDict
2. Alter the keys on the DynaDict so that they are guaranteed to be unique for all possible instances of BASKET that could be added to that DynaDict

It's difficult to comment on which is the most appropriate option for your situation as we don't know the usage pattern for this DynaDict. For example, if you're not relying on there only ever being one object that is a match for a given key, or keys, option 1 would be the easiest to implement. However, if you need to rely on there only ever being one object that is a match for a given key, or keys, then you'll need to take option 2 and ensure you have appropriate keys on your DynaDict to ensure that no two instances of BASKET could ever result in a duplicate key error.

Cheers,
BeeJay.