Adapter can be started by following the standard steps and specifying the parameters in the configuration xml. SessionConfiguration event should be send before sending any other event. Following should be the format for SessionConfiguration event:

where first parameter is the transport name and second parameter should always be "KDB"

logFile should be given fullpath to the file location

After that database related events could be send, e.g.

where trade is the table name already present in the database which is being created in the database by the following statement:

Transport name should used in each event as database name since transport would be connecting to only one database.

Upsert statement can be run either by specifying the field with respective values or directly the query in the event interface. An update would be significant only in keyed tables otherwise a new row would be added with the same values in non-keyed tables.

An example of upsert event is:

where tradeKeyed is the table name keyed on time, so the record with that time would be updated. Table definition should be given in entityDefinition property of transport in the parameter file like:

Otherwise Adapter would throw an error. So, all tables need to be defined where an upsert is required.

An upsert with query only, can be given like:

If field values are null, then only it will consider the query field of the event, otherwise query would be neglected. In the above event, in extraParams, a field "async" is defined which tells that this upsert is asynchronous and the user doesnt want any response of the running, meaning "Run it and forget it". In the other case, where this field "async" is not specified, a response would be send after running the upsert.

An example of Execute event is:

where f is the function name already defined in the q database.

A function on q command prompt can be defined like:

where x is the parameter and x*x is the result of the function. This function definition should be present in the entityDefinition property of the transport, otherwise function execution would be rejected from the transport. Entity can be defined in following way:

Since functions in q dont have a specific parameter type or return type, so while defining the entity, type should be given for whatever input this function is going to be called with. Like for same function, to call it with float values, entity can be defined like:

With the execute statement, tables etc. can also be created:

A delete can also be executed using execute statment:

Function execution can also be achieved by omitting the argument name and value pair dictionary and by directly giving q language syntax of function execution in the query field of the event:

Different data types should be given in java format on the correlator side as mentioned on page 45 of Kdbplusversion3_0.pdf. For example, a data value in Minute format would be a complete integer value like 50,640 etc. but on q prompt it is given in ':' format like 00:40, 06:40 etc. So while inputting a value using an event from the correlator, a Minute type value should be complete integer. Same for Month and Second data types.

Bytes should not be given in hexadecimal format. Byte value should be given as an integer value in the byte range -128 to 127.

Real types value can be suffixed with 'e' but power should also be specified. Like '2.3e' is valid on q prompt but will not valid through the adapter. Instead of '2.3e' , valid format would be '2.3e0' which specifies the exponent power as zero.

Long and short should not suffixed (with 'j' or 'h' respectively) as on the q prompt. But an integer value should be specified in their respective range.