What's your target for this? Developers writing agents using SQL withing the agent to query the database? If it's restricted to working on the view indexes it might be interesting, but if it needs to go into docs, then you'd be just as well running and db search. Also if the query was hard coded, you would be MUCH better off just building a view that has the data you need.

Or am I missing something?

My thoughts on this would be to pass a request to an agent via a GET or POST and have that agent return the result set. It should NOT require any views to be built to handle it. In addition, it could act much like the RSS database template in Domino 7 in that you could have 1 web service per server to gather the data. In addition to the normal SQL commands I mentioned above, there will also be an attribute to allow the user to determine the format of the data returned (CSV, JSON, XML, Word/Excel).

Rather than a query, simply do a view getdocsbykey, you can either concatenate the "keys" into one column or pass an array. Also w/Domino8 you can store a Notes Database in DB2 natively. Then you can do DAVs as a "normal" view or a Query View which is basically what you are asking as you use a Query to create the views collection of data notes/documents. See the Notes Designer8 documentation on { Link } for more information.

Actually I'd like some way that our users could type an SQL command and get output to a console/window. Ideally they could save these for regular reporting, perhaps even have the results emailed to them automatically on a certain interval (daily/weekly?).

Eh...I think that as DB2 is now a native data store, this isn't so much an issue. I'd rather have access to use my iSeries db2 without weird workarounds.

An SQL interface to Notes data would be perfect for reporting as Bob Balaban noted in his blog about NSFDB2.
{ Link }

It just would be nice to have SQL against an NSF without the need to go full-blown to NSFDB2 which is not an option on platforms like System i anyway.

I totally buy this idea. If you try to implement a new application/database for any client and you know that in the requirements is reporting, it's the one thing avoided like the plague.

I'm faced with three options that I know of, and have been discussed here:

Native DB2 - why do I not see this being pushed by Lotus? I read all the blogs, I run the latest builds, etc, etc, but is it really being pushed as viable?

NotesSQL - I gave up on it years ago because it was so flakey and required desktop install. It was quicker to dissect the NSF with an Hex editor than wait for results sometimes. Is it really better now? If so, I'll give it a whirl.

Cross-storing data or writing relatively "slow" agents - yeah, we've all got great ways of getting out what we want, like views categorised on numerous elements and so on, but it's all workarounds to something that should be native, fast and efficient, for both "super users" in a community, or for developers

Step outside a moment, and picture going into a "report writer" module, where you pull disparate data together from across your database into one report, based upon prompted variables, SQL joins, and other very old and simple techniques ... man, that would ROCK MY WORLD! :-)