Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: beginner on June 15, 2010, 01:58:28 am
-
Does anyone have an idea where to find the note links attached to connectors? The note does not have a connector itself. So I suppose it's somewhere in t_xref. But I could not find the note's GUID.
b.
-
Zarquon says-
It looks like the note link is stored in t_object in column PDATA4 in the row for the Note object itself as "idref1=<Connector ID for the first linked connector>;idref2=<Connector ID for the second linked connector>," etc.
Fred W
-
Or "How NOT to build a relational database" :o
Geert
-
Thanks from the Great Handkerchief. I'm sorry that there are still some Jatravartids left in Australia working on a strange database with 50 extensions.
b.
P.S. it appears that in this very case MiscData is not populated with PDATA. JAEAB (just another EA bug). I will have to use SQL...
-
Bless you.
-
P.S. it appears that in this very case MiscData is not populated with PDATA. JAEAB (just another EA bug). I will have to use SQL...
Um no, it does seem to be populated correctly. Try this script:
/*
* Script Name: Link Test
* Author: mfraser
* Purpose: To prove that the automation interface isn't broken in this case
* Date: 2010-06-18
*/
function main()
{
// {6ED50893-BACF-4e1e-A255-119C4D0B9D04} is the GUID of my linked note
var theElement as EA.Element;
theElement = Repository.GetElementByGuid( "{6ED50893-BACF-4e1e-A255-119C4D0B9D04}" );
// Misc data is 0 based so PDATA4 == MiscData(3)
Session.Output( "[" + theElement.MiscData(3) + "]" );
}
main();
Which raises 2 questions:
1. Which element are you inspecting PDATA4 on: the Note or the Connector (should be the note)
2. Are you taking into account that MiscData is zero based?
-
As I wrote to Allan, it is (likely) Perl/EA communication which is causing the trouble. MiscData is undef in all cases. There had been a workaround for GetTreeSelectedObject which was behaving differently for interpreter languages. I can't recall other places where arrays are returned, just scalar values. So the array handling might be wrong.
b.
-
Just as a blog entry: it appears that sometimes PDATA4 contains zombie entries. That is PDATA4="idref1=59255;" where 59255 is not in the database. I ran consistency check several times but the zombie remained. JAEAB
b.