ExportPackageXMI

[jeffc030]

I am creating packages using SQL, and am trying to export a newly created package using the ExportPackageXMI function.  The call returns "Unknown Package".  I have tried reloading the project using Project->ReloadProject(), and that returns successful, however the export still gives the same response.  

I could try using the EA API to create the new packages, however I found that it was a little more difficult when trying to determine if a package already exists.

Any ideas?

Thanks.

[«Midnight»]

What I always seem to do, when I'm trying something for the first time, is create a package (or whatever) and then try to use it. After a bit of hair-pulling I always find that I've forgotten to (either or both) call the .Update() method or more likely, to call the .Refresh method of the parent collection.

In the latter case (forgetting to call .Refresh) the result would be similar to your problem.

Reloading the project should put things right, but who knows.

Please let me know if that's what's happening. I am soon embarking on some heavy data transfer stuff through automation, and I'd sure like to know if this is going to be a speed bump.

David

[jeffc030]

I am calling Rep.RefreshModelView() after creating the packages, and I just now tried calling Update on the root package after using Rep.GetPackageByID() which did not work.

I am inserting the new package into the t_package table using INSERT INTO setting the ParentID, ea_guid, and the name.  I can see the new packages in the project view, and can even export them manually.  

I have even tried closing and reopening the project file, and attempting the export.  

I may have to resort to creating the Packages using the EA API.  I wanted to use SQL so that I did not have to deal with first accessing the Models Collection, and then the packages collection expecially when getting mixed results when a package already exists.

Thanks,

Jeff

[«Midnight»]

Sorry, I assumed you were going through the API. The .Update() method is required by the API to actually save a new entity within a collection (and pretty much anything in EA is in a collection, even the models themselves). You create the thing in question, set any immediately important properties, then call .Update(). You also call .Update() after changing any properties. The .Refresh() method is called on the parent collection. You only really need to .Refresh() before you reference any of the 'collected' entities, so don't have to do this every time.

I've not tried adding new entities via SQL, since this could easily involve having to tie in other tables. I have often created a second channel to the underlying database to set various properties via SQL where no EA capability exists. The latter approach is simpler as long as I don't manipulate any fields that are tied to other tables - the links - and thus the side effects - are undocumented.

The big question here is whether there is some other table that you need to tweak before EA fully recognized the Package. My guess is that you should look at t_object. All packages have an underlying Element entity that contains the element-like attributes of the package. Thus, all packages also must have a record in the t_object table. Create a very small model via the EA UI, close it, and look at the two tables. That should give you the hints you need.

Please let me know how it comes out, once again. This is beginning to sound interesting.

David

[Eve]

All packages (except root nodes I think) have an entry in both the t_object table and the t_package table.  The t_object.PDATA1 column gives the package id when the object is a package.

That should get you going.

[jeffc030]

Well, it turns out that the guid I was inserting was not enclosed in "{ }".  I noticed this difference between my newly created guid, and the existing ones.  Made the change, and it seems to work.  

Thanks for the help guys.

[«Midnight»]

Good going Jeff!

Just to be sure, what you are doing is creating an element (or package or whatever), then setting the GUID to something you created.

As I understand it this is possible via the API as well - with the caveat that you must set the GUID and call .Update() before you do anything that would reference the element.

I have a possible use for this sequence of events - versus having EA generate the GUID for me - but have not taken the plunge as yet. Knowing about the {}s will certainly save some of scant hair when the time comes.

David

[jeffc030]

Yup, when I insert the new package into the t_package table (and t_object table) I have to assign the GUID.  I am using the .NET Guid.NewGuid() function.  

I am sure you have to call update() on the new element if you want to access it via the API, however all of the element manipulation I am doing is in SQL.  I am just creating new packages and moving existing elements into these packages by changing the parent_IDs.  Does not even seem like I have to call update to do the export.

-Jeff

[«Midnight»]

Makes sense. I think that the .Update() call actually stores the record in the table(s). Like you I expect to get the GUID from .Net, or perhaps from a SQL Server database UniqueIdentifier field.