-addndt template: pers?clnt=<name|pass>&com=addndt&sid=<id>&usr=<usr>[&tms=<timestamp_pattern>]&<ftr_1>=<value_1>&<ftr_2>=... Order of query params are not important: the timestamp applies to all features in request. Feature values must be numeric. pattern : - | <date/time>, where '-' means that the PServer assigns a transaction timestamp, otherwise the <date/time> provided by the application is used. The <date/time> format must be a long integer giving the milliseconds passed since January 1st, 1970 00:00:00.000 GMT. The pattern is optional. In case it is missing, its value is assumed '-' (PServer assigns a transaction timestamp). descript: for the specified user and for each 'ftr' parameter in the request, a new tuple (user, feature, value, timestamp, sid ) is inserted in table 'num_data'. In case the timestamp is provided by the application, it denotes when all the (user, feature) interactions took place. In case the timestamping is is delegated to PServer, it is the date/time of the insertion of the tuples in the DB (the transaction time). In both cases the timestamps can be used to put feature interactions in the order they occured. For this however, timestamping of all features must be consistent and correct (either PServer or application generated, not both / mixed). If a request contains many features they will have identical timestamps. This does not create any problem as long as the features are different. If the sid is ommited then the last sid is assumed to be the desirable. The DB however cannot record more than one identical (user, feature, timestamp, sid ) tuples. For timestamps that are the same, the order of the corresponding interactions will be arbitrary. If a timestamp pattern is not legal, or if the request leads to two or more identical tuples, or the value of some feature is not numeric, 401 is returned. If the error code 401 is returned then no changes have taken place in the DB. example : pers?clnt=name|pass&com=addndt&usr=kostas&tms=1005854668670&laptop.weight=2.55 returns : 200 OK, 401 (fail, request error), 501 (fail, server error) 200 OK : in this case the response body is as follows <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="/resp_xsl/rows.xsl"?> <result> <row><num_of_rows>number of relevant rows</num_of_rows></row> </result> comments: the reference to the xsl file allows to view results in a web browser. In case the response body is handled directly by an application and not by a browser, this reference to xsl can be ignored.