When you create a report into myDBR two things need to be done.
- Create a stored procedure with sp_DBR-prefix
- Attach the procedure as a report to myDBR (give it a name and a location)
When you first click the 'Add report'-button, myDBR asks for the procedure name and creates a skeleton for the procedure. Once you have created the procedure in SQL Editor, myDBR will bring up a button 'Add report to myDBR' directly in the SQL Editor.
If you click the 'Add report'-button when you already have report routines that have not yet been attached as reports, myDBR will offer for you to do that.
Allowing the user freedom to create the sp_DBR in an external editor and then "Adding" the report using the "Add report" button would be much better frankly.
myDBR reports are normal native stored procedures. You have absolutely the freedom to use any external editor to create/edit the reports. In many environments, direct access to the database is prohibited. If you have an access with an external editor and prefer to use it, feel free to do so.
myDBR's SQL Editor offers some quick tools for you when you create the reports. Try highlighting an object (routine, function, table, view, or a myDBR command) and click the 'Show selected object' button).
OK, I think I figured-it-out.. I had to use the 'mydatabase..mytable' convention to tell myDBR which tables to read from and the sp_DBR function is actually stored in the myDBR database NOT the user report database.
The SQL you write is standard SQL, not myDBR specific one. If you installed (the default) myDBR into its own database use the syntax
database.[schema].table in SQL Server and in Sybase and
database.table in MySQL/MariaDB.
You can also install myDBR into the same database as your data (myDBR has its own naming scheme so it will try not to conflict with your tables/routines), but by default, it is installed into its own database.