run dql

There are several ways of running dqls in the server.

Write a dql in the page/template/element by starting it with .dql at top part of the page. The end of the dql is the next .command
use definition to test or run dql by /definition/testdql or /definition/rundql when you are logged in as a superuser with High as level
use the /run/dql/dqlname command where the level set in the dql will determine who can run it
use execdql in any of the others

The page dql

This can be run as part of any page. There is a whole chapter of how this work later in the book.

The definition based dql commands

This way of testing and running dqls can be done with any dql code that you might have. There is no need of storing the dql in any way like the others. To be able to run a dql in this way you must be logged in with a user that have the user level set to 1 (High).

To test a dql and get back data-entry used and the tdf for output you can call /definition/testdql with GET, PUT or POST verb. The first expect a url encoded query string named code and the two others expects a payload of json where there is a key named code. This command will return a json with result:"ok" if it compilation is successful and result:"error" if not. It will also return with a jdata.dqldefinition.default key with the definitions.

All ok definitions

dataentries	A string list of data-entry that is used by the dql. Ex. ['field1','fname'] is two data entry in use. To send it to this dql you have to add ?&field1=val&fname=val2
multiview	A multiview definition of the output from the dql. This is a array of definitions. In each of them you will find fdefs Ex. jdata.dqldefinition.default.multiview[0].fdefs gets the first field definitions

Error definitions

error	A message telling what was wrong.
errorno	The error code returned by prism
errorpos	The position where the error was found in the code.
errorincode	Take 100 char of the code and show where in the code the error was.

The run dql path

Syntax: /run/dql/[name][execdqllookup]/[bodyname][execdqllookupbody][bodyfieldinexecdql]?&query

To run a direct dql in the server, you can to use the /run/dql url. The dql can be stored in WebServer table, in file or in a defined dql store. To be able to use security settings, it has to be store it in WebServer table (or other defined table) or in a dql file and it will be looked up by the name given from third url part. The query string can be used as data-entry in the dql.

Ex. GET /run/dql/createanewcustomer?&field1=DataEase%20Ltd will run dql from WebServer table with name createanewcustomer and given data-entry field1 with value "DataEase Ltd"

WebServer table

It has to be assigned a user level to be able to run. If not set, the level High will be automatically be used. This is then called with /run/dql/dqlname where the dqlname is what is set as name in the WebServer record.

The dql are either run in page mode or execdql mode based on the content. If it start with .dql (or any other .command) on first line, it will be run as a page dql. If no .command it will be run as execdql. Whatever mode is used, will give a result in the form of json with result = "ok" if we where able to run the dql and "error" or "denied" if not.

Page based dql

Page dqls takes any query parameters as data-entry and will return the data in the same format a page with json=1 set in query will do. Templates and elements defined will all be ignored. Only code on the page will be run.

Execdql

Execdql style dql takes field1-4 from query parameters and used them as data-entry field1-4 and will return the output from the execdql in "data" key either as a string or a json object based on if the return from the exec dql is starting on '[' or '{' or not. You can add your own template to use with the execdql by adding a @, #, *: or named body. The named body is read from WebServer table using the name for lookup. The others follow the rules for dql store of file based dqls.

DQL store dqls

I names given in url starts with @ or # (in url you must use %23 instead of # as # is used for jump to paragraph in htlm), you will run a dql from the defined dql store. Default name is "$$DQLStore$$". To use a different one, used normal mechanisms to set a different one in rdrrXaaa.ini. To be able to run execdql direct, you have to be logged in with user level High. If you want to use execdqls with a lower level, just call them from a page based dql. The possibility to run direct is only meant for development and debugging.

When first part is a execdql lookup for code, the next can be the same for body or just the field name in same table as used for finding code, but this is only triggered if no .command is the first line of the dql as it then go in page dql mode.

Ex. /run/dql/@GetCustomer/Body3?&field1=DataEase* will find execdql code in normal dql store and find the body in field named Body3 then run it with data-entry field1="DataEase"

File dqls

Files can be used for loading dqls. The format is *:filename.dql where *: will be replaced by repopath\dqls or what is set in rdrrXaaa.ini for dqlpath. The page mode or execdql mode is triggered by if the first line contain a .command. If not page mode the next url part is used for body if it exists. Body is looked up by the same rules as any other execdql in WebServer table mode.

ExecDQL

The exec dql can be used in any of the other dqls. It work the same way as classic execdql. You can use the settings in rdrrXaaa.ini file to set where and how it is looked up. The difference from normal execdql is that it will look in the [server] (or what is set by --prefix=) section first to see if there are settings before it do the normal settings.