deciphering EA-GUID in Access

[Deborah]

Hi there:

I am trying the nitty-gritty approach of importing requirements directly into access: creating packages and objects.  So my questions are:

1) It appears to me that the t_object and t_package tables are the only ones requiring direct fiddling.  (and potentially the t_diagram table to automatically generate a diagram, although that seems more involved)

2) How come the EA-GUID field is so creepy?  Do the parts of the id signify important stuff, or is its purpose solely to be a unique id?  In the latter case, could I just add incrementing #s for my importing requirements EA-GUID?  I tested this on a sample project, and it worked, but I don't want to implement it until I hear from you guys that EA won't blow up in some weird way.  And, if incrementing #'s won't work, what does?

Thanks for your attention,  
Deborah    

[gsparks]

Hi Deborah,

The ea_guid field is a system generated random identifier. It is created in C++ with a call like:

         GUID guid = GUID_NULL;
     CoCreateGuid(&guid);

then formatted into the string you see in EA.

The formatting and content is significant .. so you cannot substitute 1,2,3,4 .. some functions will fail if you do.


Ideally, you should generate GUIDs using the same call. The knowledge base article at :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q176790
shows you how to do this in Visual Basic - make sure the final format is identical to that used in EA (including { and })


If this is not possible, the only alternative would be to take an existing GUID and increment some part of its internal structure. Due to the randomness of GUIDs, you are very unlikely to strike a duplicate unless you generate a very large number of these things.

For example you could increment the final "729190" in the GUID  {C8200F4C-8318-4a52-9895-7789AA729190}

and create a series of new numbers based on the original.

Hope this explains,

Geoff Sparks

[Deborah Johnson]

Hi:
For what purpose is Field1 used?  I'm using it to store a unique identifier that links requirements to another database we are using.  Please tell me this won't cause problems!   (Although I want the truth too)  So far, everything seems to work fine with this implementation, which I prefer as the identifier appears hidden and thus removes the possibility of modification in EA.  IF this is a bad approach, could you please suggest a place in your objects table?

BTW, thanks so much for the reference to that guid-builder.  I now have my program outputting guids in the same format as yours    

Thanks for your help,
Deborah

[Deborah]

Sorry about my above confusion.  I (haha) added Field1 and didn't realize it to a sample database for EA.  My real question is: within t_object's text fields for requirements objects, which can I use to store a unique id from another database, that will not disrupt the flow of EA, and ideally not show up for users?  For instance, for a requirement object, can I store this id in PDATA4 or PDATA5?  These appear to be empty fields for this object (I would only need this for requirements).  If this can cause problems, which fields will not?

Also, could you keep this need in mind for future builds?  (leaving a hidden, unused field for integration of various databases)  This would help us A LOT!

Thanks so much,
Deborah

[gsparks]

Hi Deborah,

Yes - I read your note earlier and was confused over what Field1 referred to.

The ideal I think would be to add an entry in the Tagged Values table for t_object  - which is t_objectproperties. You would fill it in like this:

PropertyID - counter field, updated automatically
Object_ID  - object ID from t_object table
Property    - name of property - eg. "user_ref" or "x_ref"
Value        - some meaningful value for you
Notes        - optional comment
ea_guid     - unused currently - may require population later

This has several advantages:

- It is easy to do and does not break any exisiting code
- It is extendable - you can add as many properties as you like
- The value will be saved and restored in XMI import/export
- It is user visible ... this may not be significant in the current instance, but in some cases it may be useful
- It is reported in RTF and HTML documents - so the link is visible in reports

For reporting a cross reference purposes you would need to modify your query to join the t_object and t_objectproperties table on Object_ID - and add whatever other filter criteria you like.

This is not as easy as working with a field in the t_object table I admit, but in the long term I think it is simpler and much more 'open ended'.

I would not suggest using the PDATA fields as even though they are unused for Requirement at the present - that may not always be the case. I would hate to inadvertently overwrite all your links!

Let me know if this is OK or not, or if you need any help in working with the tagged values table.

Cheers,
Geoff Sparks

[Deborah]

Thanks for the idea.  I created the queries for lookup -- insert, and the insert failed (the select query succeeded).  Using correct syntax, I've attempted insert from the exact query I wanted, to now trying a tiny test to insert anything.

Each time I get an insert syntax error.  Is there some sort of weird permissions or is the table hooked up to another?  The problem is bizarre, because I can successfully insert into t_object and other tables.  Please let me know if there's any trick to this, because the problem is really weird.

The tiny test query that fails is as follows:
"INSERT INTO t_objectproperties (Value) VALUES('latida');"

Que pasa?
Thanks, Deborah

[gsparks]

Hi there,

The problem is with the column name "Value" - this was a bad choice for a column name as it is a key word in JET SQL. Whenever referencing this column in sql you have to wrap it in square brackets to tell the SQL processor its an ID, not key word. So the sql should look like:

Insert into t_objectproperties ([value]) values('something')

Hope this straightens things out,

Geoff Sparks

[Darren Lock]

Geoff,

I wonder if there is an EA extensibility requirement developing here? For some time I have been modelling requirements by creating External Requirement elements (through the EA GUI not directly). The Requirement Details are a cut & paste from the Business Requirements document (Word). I then create a bookmark in the Word document based on the number I have used to prefix the Requirement Short Description. Finally I had a file:// URL to the Files section of the Requirement to point to the bookmark.

Thanks to your latest HTML generator I can now publish the Requirements Model with hyperlinks straight into the Business Requirements document.

You can see where this is leading to.... What would be really good is an automation method to create the Requirement. In Word I can create code to create the bookmark and then create the EA requirement. Now that would be great... and a lot quicker than the the current process (I am managing >500 requirements currently ). I have avoided any form of direct database update for the reasons/questions that Deborah has indicated and an auotmation interface would hide the detail of the underlying rules and thus be more future-proof.

Are there any plans for a full read-write interface in the near future?

Rgds, Darren.

[Deborah]

Thanks for being so prompt!  It works, and I like this solution better than inserting the id into the object table.


Deborah

[jodo]

Hi, in an earlier post by gsparks on 4 June 2002, it says "ea_guid - unused currently - may require population later".  In Enterprise Architect 3.60, is the EA_GUID still not required, in particular for the t_attiributetag and t_objectproperties classes?  Basically, would it be okay to insert rows into these tables through an external application, and still not affect proper functionality when using the datafile in Enterprise Architect?

Out of curiosity, what would the EA_GUID be used for anyway?  Is it a means to synchronize data?  It would seem that the particular entity ID should be a sufficient unique identifier.