Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arquesoft

Pages: 1 2 [3] 4 5 ... 9
@qwerty: I'm not pretending to generate the MDG "dinamically". It just have to be updated from time to time (aprox once, every 6 months). This is because we create new stereotypes we have not considered before, or add/modify tag values to old ones.

@Geert: previously I considered MDG generation as a thing created in setup time. That is why we didn't create any special way of storing the MDG, except the profile definition itself in the model. Your approach seems logical to me, so I will make the suitable changes in order to consider the MDG generation as a code compilation. Thanks.

Really I was expecting some solution as "make an environment variable and...", but the solution of Geert seems fine.

Hi, I would like to read your opinions about a good strategy in order to let different users to generate a profile (or MDG), having in mind the icons are defined as local file for the user is creating the profile.

The scenary and restrictions are:
  • There is a shared model in a database
  • Multple users want to update the profiles via re-generating the profile files and the MDG files
  • The profile definition exist in the same model (so, we have to generate the MDG and import the MDG in the same model)
  • It is not possible to have a shared folder to share the icons

Do you know any way to define the icon folder via a parameter or something not depending on the user creating the stereotype in the profile?

Bugs and Issues / Re: Synchronise Stereotype via API odd behaviour
« on: June 01, 2018, 01:32:27 am »
Sure, qwerty, but the t_xref table apparently stores an identifier of the GUID of the stereotype (or profile, or MDG, or something that is different for every publication of the new version of the profile). I suppose it could be useful if you return to a previous version of the profile, or to check if the version of the tag values of the element matches the tag values of the profile. (just guessing)

Bugs and Issues / Re: Synchronise Stereotype via API odd behaviour
« on: May 30, 2018, 08:44:13 am »
It is a known issue for me. When you have had several "version" of your MDG (profile), it is possible you have several elements, each one using a different version of the profile stereotype. When this is the case, you can note that t_xref table stores the reference to the GUID of the stereotype in which the element was created. So, it is possible to have different elements of the "same" stereotype, with different entries in the t_xref table, referencing the "same" stereotype but in different versions.

What have I done? Some of the above, but I have found it doesn't work 100% of times:
  • Delete manually the stereotype entry in the Stereotype configuration window
  • Delete the t_xref entries for the stereotype and the element (note there could be different entries in this table for the element, not concerning to the stereotype)
  • Run your script that syncronize the tag values
  • Restart the application, and if it is an shared database, make the other users restart the app.

If you use Cloud Server (it is free and very easy to install), the Cloud Server can generate periodically the points of the graph if you use the second alternative and your query strategy for postgres. If I were you, I would use the query.

Are you using legacy reverse engineering? Have you tried Database Builder?

Two approaches:

1) Avoid automatic calculation of timeseries chart (which only works when having Cloud Server), and manipulate the data of the chart via a custom script that calculates your data and stores it in the suitable tag value of the timeseries chart (the data is stored as an XML). Just a programming solution.

2) Use some query that returns as rows as the value of your current dot in the graph. For example, the following SQL returns 10 rows (change the 10, and return different number of rows). Works in SQLServer:
Code: [Select]
SELECT TOP(10) 'true'
FROM sys.columns AS a CROSS JOIN sys.columns AS b

I created a C# console app that works fine in development environment and in production environment (windows server 2008 R2 64 bits) but only when executed manually. When scheduled in Windows Task Manager it throws the following exception:

Retrieving the COM class factory for component with CLSID {67F4E0FA-46A7-4255-B084-69A9433D08C3} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

I followed the instructions described in:

But when trying to find the EA.App component in the Component Services windows, it is not listed, as shown:

Even in my local PC (windows 10, 64 bits), the EA.App is not listed. Note the shortcut of the comexp executable:

I followed all the instructions in the previous links, even in my local PC but the EA.App is never listed in the Component Services window, so it becomes imposible to configure full launch permissions to this component.

Any ideas?

As it seems there is no way to include triggers in the template editor, you can explore the database in order to determine how your triggers are stored. Then, you can do a Document fragment to get the information of you trigger via an SQL. After that, just include your fragment into your document.

I did it!

Bugs and Issues / Re: V14 different browser order
« on: May 16, 2018, 02:41:42 am »
Corrected in today build (1420). See

I could 'unhide' the hidden baselines by executing the following SQL in the database:

UPDATE t_document SET ElementID = SUBSTRING(DocType,12,38), DocType = 'Baseline' WHERE DocType LIKE 'BaselineOf={%};'

Hi, I have just noted some inconsistent data in a SQLServer model about baselines.

I've been using in the last weeks different versions of EA (Build 1310, Build 1351, Build 1352, 14 Beta 1, 14 RC 1, Build 1418 and Build 1419).

I have a script that creates baselines for a list of package GUIDs. I've run the scripts periodically and it used to work by april 10.

Now, I noted that data is inconsistent in the database, for the following reason:
Table t_document is supposed to store the baselines. I had several data in which column 'ElementID' stores the GUID of the package with the baseline, and the column 'DocType' stores the string 'Baseline'.

But now, I have data of table t_document modified and the same entries (recognized for DocID field) have now another data for column 'ElementID' (not a real element guid), and field 'DocType' now stores the string 'BaselineOf='{THEGUIDOFTHEPACKAGEWITHTHEBASELINE};'

Obvuiosly, EA does not detect this modified entries as baselines of the package, so the baseline list for all my packages are empty, but I still can see the entries in the database.

Any idea of what to do? what make this happen?

(I know a solution is to restore the 'ElementID' entries based on 'DocType' entries but I need to know what make this happen).

Now, when creating a Diagram Legend, it is visible in the Project browser but without name.

So I've just got some clarification that to fix this problem with SQL Server you need to apply an additional patch to the schema (EASchema_1220_SQLServer_Update1.sql). This update was just recently made available on our website (April 2018). In particular, please note that it requires all users to have EA 14 and is not backwards compatible. For more details, see:

What is the consecuence of executing the SQL patch and having some users using version 14 and others using previous versions? will this bother the use of image library? or just version-13 users would be unable to upload images? Will this scenary cause errors? (asuming I pretend to upload images only from version 14 users)

Pages: 1 2 [3] 4 5 ... 9