I dont think that RunModelSearch (both in repository and project interface) can be used to populate a report with elements from a SQL query. The documentation says “Runs a search, displaying the results in Enterprise Architect’s Model Search window”, meaning that the elements are just shown in the search window but since the function does not have any return value, the elements cannot be accessed (Maybe there is a function accessing the search window, that I’m not aware of).

My workaround is, that I programmatically create a temporary diagram with the result of an SQL query, sort of a programmatical “ad-hoc” diagram. This diagram is then used as input to eaDocX (elements are formated in a table, so the layout does not matter).

OK – I have tried this, and like you, I can’t figure out a way to get a predictable result which eaDocX can understand.
So, for the moment, we’ll have to say that SQL Searches are NOT supported by eaDocX. Maybe in some future version, but it does rather go against the whole idea of eaDocX, in that we don’t need our users to understand what happens inside EA.

I’m looking at this at the moment, and I can’t EA to accept my SQL at the API, even the SQL in their supplied example. 🙁
Just so I understand your requirement fully, are you running SQL against the main EA tables (object, connector, package, attribute, method) as simple SQl (just attributes from one table) , or do you want to create more ad-hoc SQl, with joins etc, and columns from many tables ?
Have you explored getting the same data using just plain eaDocX ?

We’ve had a LONG think about this one…
We totally get that it would be great to allow ad-hoc SQL queries, but we’d need a whole new bit of eaDocX to define how the results should be formatted. Not impossible, but quite a bit of new user interface.
..but the whole reason we built eaDocX, (which was for us to use on our own projects and let non-EA experts create their own documents), was to keep people away from the complexities of EA. And certainly to keep them away from needing to understand the data model. We think that if a user understands the EA data model well enough to write SQL against it, they aren’t really the market we’re aiming to help,
..So, the result of all this thinking is that we MAY add this as a feature in a future version, but our real focus is in making EA more accessible to inexperienced users, by making it simpler.
Your other idea, of having different profiles for different sections, we think of in the same way: really powerful for the power user, but may make the documentation process more complicated for the average user.

Another thought, we came up in our discussion:
Not that it will solve your problem, but one trend our customers tell us about is that with eaDocX, because creating documents is easier, they create more, but smaller and simpler documents, for different audiences. Something to think about ?