Changing 'commit' option in XML SQL statement does NOT work about xmlservice HOT 7 OPEN

@ngson2000
The sequence is mattered. That is just a flow like calling DB SQL CLI for you. Xmlservice won't do a full parse first and then re-order to call system interfaces. Users need to be aware of that.

My network is blocked to the link you pointed out. But I searched '<options ' in the document source. I noticed all examples having ahead of . That is correct. Can you reference a piece of text from that webpage where it tells a wrong usage. BTW, I don't think that webpages will be maintained even if things are corrected in here. All will go Github.

from xmlservice.

@jimobit The link points to the wiki I dumped in to the docs directory. The local text is https://github.com/IBM/xmlservice/blob/master/docs/wiki-dump/functions.txt#L1270-L1293

from xmlservice.

Reminds me I should work to get #40 merged

from xmlservice.

Thanks @kadler
What @ngson2000 referenced was not an example :-) It explains the definitions of and . It doesn't indicate the declaration orders... Please refer to other pages with real example snippet...

from xmlservice.

So from what I gather, an options template is basically an object which gets instantiated. In order to use it, you must have already declared and instantiated it, so the order of the tags matters. From what I can tell, it doesn't matter the order of the attributes within the options tag, however.

It seems like options objects stick around between calls in stateful XMLSERVICE, so you can instantiate one once and re-use it on subsequent calls. For normal stateless XMLSERVICE, you wouldn't be able to do this though. This means you must also free the options object after you are done with it, just like other SQL objects.

from xmlservice.

We should definitely work on documenting these restrictions and obligations better.

from xmlservice.

Yes you are correct. Looking at the cacScanOpt(), 'options' cache is designed to be common to all other tags with 'options' elements. For stateless, the cache should also work before cache is cleared out when the call is ended.

from xmlservice.