Forums

I've managed to introduce the same translatable string into 2 schemas in Jade 6.3.
This now causes a 1310 key already used exception when trying to access the subschemas trans strings.

I've written a script and identified the duplicate translatable string, I want to delete it but am being prevented because it's an instance of a system class.
"Cannot delete this instance of a system class or subclass"

I suspect there will be an undocumented way to delete this instance.

Any ideas?

I doubt someone will tell you on a public forum if there was!
Can you instead change the name with setPropertyValue or does that give you the same error?
This is a Jade bug so the support team should provide you with a proper fix.

I'm not sure how you've managed this as I get a 'string already exists in superschema" or a "string already exists in subschema" error when trying to setup this situation in Jade 6.3.x with the IDE.

Have you considered creating a new 'temporary' translatable string in the superschema, move all references to the current string to the 'new' string, then remove the superschema instance of the duplicate string. This may then allow you to remove the version in the subschema as well. Then, you could put it back to the original name again in the superschema by re-creating the original string name in the superschema and change all usages of the 'temporary' string back to the original string name.

Hope that helps,
BeeJay.

Any thoughts expressed are my own and in no way reflect the views of my employer. If this reply includes any sample code, or other changes such as registry key settings, I believe that this information is accurate and reliable and has been prepared with care but give no guarantee that the sample code or suggested changes will be free of defects or errors. No responsibility or liability, financial or otherwise, is accepted for any consequences arising out of the use of any sample code including loss of profits, indirect, special or consequential losses or damages.

ParentSchema
ChildSchema

I loaded a schema extract that included a TString defined in ParentSchema into a different system that already had this TString defined in ChildSchema.

When I (or the JDE) accesses all Strings it copies the collection from each schema into one collection, this is where the key already exists pops up.
The String browser is hitting this error, which is why I turned to a workspace, I can target the 2 schema collections from a workspace and identify the offending TString object, I just can't delete it.

Luckily this is a Test system, I'm surprised by how much grief this is giving me and also that I have never tripped over it before. While I have this happening I wanted to work through a quick fix in case it ever happened to a production system.

The system is not available at the moment as I'm running a Certify.

I'm sure Jade Support have given me scripts in the past to deal to something similar to this.
As it's just a test system and 6.3 is sooo old I thought I'd hit the forums before bothering with Jade Support.

I gave this an inaccurate title, should have been: How to delete an instance of TranslatableString, which is a System Class.

Oops, the JDE only throws an error when opening the Strings browser for the ChildSchema, which is ultimately where I want to remove the duplicate from.

However, I can simply open the Strings browser for the ParentSchema and delete the duplicates there... then just set about shifting these Strings into the correct schema.

That's what I was suggesting in my first response, that you may be able to remove the 'duplicate' from the superschema using the JADE IDE.

We have a similar 'issue' in our system, where we want all the translatable strings to be defined in the superschema. However, it's very easy for a developer when using the F6 shortcut to turn the selected inline string into a translatable string to forget to select the superschema in the 'Schema' combo on the 'Add String' screen. We therefore have one of our nightly unit tests which scans for translatable strings which have been created in the 'wrong' schema and reports an error if it finds any which have been defined in one of the subschemas.

Cheers,
BeeJay.