Recent Posts

1

Automation Interface, Add-Ins and Tools / Re: Where is diagram layer data stored?

« Last post by qwerty on Today at 08:20:26 am »

Bluntly, no. I would not mind if the DB design were not optimal. But that database has so many flaws that it can be called broken. And no attempt to fix it. It's just getting worse over time. I mean, they change the UI completely each version without having any pain (those customers are just a PITA, right?). But that DB is nothing more than a patchwork. With more patches coming each release.

q.

2

General Board / Re: Import controlled lists from say Excel

« Last post by Sunshine on Today at 08:13:59 am »

There is a built in CSV importer/exporter but unfortunately it doesn't do attributes.
The other options are;

• Look at Office integration MDG add-in which will cost a few $$. The on-line help indicates you can import attributes from an excel file but I've not tried it for importing attributes but I can confirm it works for packages and objects.
  https://www.sparxsystems.com/products/mdg/index.html#office
• Write a Script in JavaScript, JScript or VBScript. If you look at EAScript Lib you'll see some CSV library scripts that would help get you started.
  
• Write a JavaScript-Addin - similar to the previous option but implemented slightly differently.
  
• Write a C# .Net Plug-in
  

If you are not a programmer then option 1 is probably the way to go. You can down load a free trial first to see if it does what you want. If you are a programmer and have time then it will be fun doing one of the other options.

Hope that helps.

3

Automation Interface, Add-Ins and Tools / Re: Where is diagram layer data stored?

« Last post by Sunshine on Today at 07:23:52 am »

I once had to coach a retrained welder (for the IT department). Judging from that guy I'd guess that Sparx employed retrained farmers.

Bit harsh on Sparx there mate. Get out the wrong side the of the bed today?

I suspect back in the day like many vendors when they change the database schema it caused a whole world of pain for customers to upgrade so they tried not to change the schema since. To be fair they done a pretty good job of fitting new features in to the existing schema over the last decade or so. But I guess there is a balancing act. At some point there comes a time when they can't squeeze any more into the existing schema without making it real ugly and just have to bite the bullet. Maybe its close to that point now.
I'm sure most customers wouldn't mind running a DB script over their DB to upgrade the schema. Its just got to work without any issues.

4

Automation Interface, Add-Ins and Tools / Re: Where is diagram layer data stored?

« Last post by qwerty on Today at 05:29:17 am »

I once had to coach a retrained welder (for the IT department). Judging from that guy I'd guess that Sparx employed retrained farmers.

q.

5

General Board / Re: Getting Current User for Javascript Add-in

« Last post by BrianYee on Today at 05:01:04 am »

Thank you, qwerty. This works.

6

Automation Interface, Add-Ins and Tools / Re: Where is diagram layer data stored?

« Last post by MichaelJ on Today at 02:52:38 am »

..."Thou shalt not change the Database Structure"!...

Lol! That's funny in the context of it being a religion at Sparx HQ.

The uneasy thought about this "religion" is that they are going down a world of hurt. It is not good data design to simply add key/value pairs ("metadata") to an object where no logical relationship exists between the object and the metadata. For example, in this post raised by Ian, they use "StyleEx" column to hold data about "layers" and "layer elements". As experienced modellers, we understand it is better to model this data inside one or more separate tables. These tables then hold data about the "layers" and their "layer elements", since there is a known relations to each other. (for example introducing the new "t_DiagramLayer" as you mentioned)

The fact they cram this "metadata" into a column that logically handles "styles", is evidence this was a conscious design decision by some (inexperienced) individual/developer. Sure, introduce new features with the least amount of change possible. No problem. However, this “Layers” feature is poorly implemented (as usual). It begs the question: was the implementation approved by actual modellers? Clearly, no. A product must be adapatable to future changes and to the needs of its customers. If DB structures must be changed to liberate new features, then surely, so-be-it. And the changes are handled carefully with  Development, Product, Test/QA before release.

What do you think, in your opinion, is the reason the EA team are not able to realise DB changes and resort to weird hacking of the data (which then introduces bugs into the product and just frustrates users)?

7

Bugs and Issues / Re: Kerning and auto-widening

« Last post by MichaelJ on Today at 02:14:11 am »

Yeah. It's that marketing team from Sirius Cybernetics Corp. which started ruling Sparx a long time ago. Ever since I see just feature creep and no bug fixing. When does this revolution come?

Wow, loved the link thank you! The first few opening sentences reflect the truth we have to face daily in EA. The statement "...not known for the quality of their products, and almost all of their known inventions are faulty..." is pertinent.

As for "Revolution"? Major external big-name reviewers such as Gartner and their "Magic Quadrant" provide us with an unbiased business-case assessment of vendors at play within a given market segment. I think the only reason (or opinion) EA survives to this day, is their relatively low cost to entry. Also, the general lack of a viable and cheap competitor with similar or better functionality, user experience and feedback system. I do wonder, as more customers use the product, and note it's awful and inconsistent user experience, surely they must demand better software from EA?

In demanding better software from a vendor, customers help by logging bugs and features. Unfortunately, in EA's scenario, bugs are never fixed, and feature requests might as well not exist. The team seem to operate with arrogance as though separate from paying customers, such as you or me. No matter how deeply you provide insight into the nature of EA's software bugs (and potential resolution), the development team know better. And release-after-release, bugs remain and UX remains stagnant and difficult.

"Revolution" will come when customers reach the "point of no return" and decide that the effort made to support the product far outweighs the "rewards". Put financially, customers stop paying for a license to use a product that no longer serves their modelling needs in the way they require.
 
 

8

General Board / Import controlled lists from say Excel

« Last post by Andy M on Today at 12:27:28 am »

Hi,

Is it posisble to import a controlled list of values to populate a new enumeration's attributes from say Excel / CSV?

I have a load of codelists that I want to show within my EA model but some have too many items to build manually.

Thanks,

9

Bugs and Issues / Re: Kerning and auto-widening

« Last post by qwerty on Today at 12:08:16 am »

Yeah. It's that marketing team from Sirius Cybernetics Corp. which started ruling Sparx a long time ago. Ever since I see just feature creep and no bug fixing. When does this revolution come?

q.

10

Automation Interface, Add-Ins and Tools / Re: Where is diagram layer data stored?

« Last post by qwerty on Today at 12:02:56 am »

The thing is, that the database structure hasn't changed in many years, and now apparently this has become a religion at Sparx HQ

"Thou shalt not change the Database Structure"!

To be nitpicky, I think the better name for this table would t_DiagramLayer without the "s"
Tablenames are typically singular

Geert

Well, at least one new table > V13.5 (can't recall which and what for but Uffe had asked for it).

q.