While I still believe that the most powerful feature of DotNetMushroom RAD is the Navigator control (for which I promise to give you an insight this weekend), the second best is the Querying facility.
In DotNetMushroom RAD one can create tables, which in the end are separate tables in your SQL database. The control panel gives you all the facility to create these tables, so that you do not need access to the server (say via RDP), you do not need SQL Server Management Studio, and most of all you do not need to execute an SQL query as a host user to create your table.

Obviously the advantage that these tables are actually SQL tables means that you might have an external application which consumes those tables. While most application requirements will not need this feature, it is still a facility for those larger and more complicated applications which maybe are integrated to your enterprise ERP system.
Nonetheless DotNetMushroom RAD still encapsulates these tables so that you are protected from other portals that might need to create a DotNetMushroom RAD application. As a result encapsulation means that you can have, say, a table called ‘Items’ in more than one DotNetMushroom RAD applications. Or, say, a table named ‘Files’ without interfering with the DotNetNuke table with the same name.

While this is cool for a DotNetMushroom RAD developer, it was a headache when we had to develop querying functionlity since if your table is named ‘Files’ we did not want you do create an SQL query with the following syntax:
SELECT * FROM tb_DNM_1_Files WHERE FileType = “Picture”
Basically our concerns were two issues:
- Your table is named Files, and that’s how you want to name it! So why the heck you should issue a query with a different file name?
- Most important our priority with this version was security, so if one can access the SQL tables directly from DotNetMushroom RAD applications, then one application could spy on the data of another application, for example if they are in different portals.
Our solution was (I was going to say simple!) that we had to build our own query engine. This resulted in a query with the following syntax:
SELECT * FROM Files WHERE FileType = “Picture”
Another application, in the same or different portal, could have a table with the same name and totally different structures and still the query engine would be able to generate the data required in that application, and from the correct tables.

Queries (and tables) can be the data source for any form, table relation field or dropdown list in DotNetMushroom RAD and the query engine makes sure that the forms get the correct data of the application.