Hi again all,

Another XML query, not sure if it's an easy one to answer though!

Is there a way to specify on the query screen how many results should be returned via XML? On my test setup I did a search that turned up over 1000 results, but the page only listed about 20 results and no pagination.

I'm assuming I'd have to work out some code to take care of the pagination (couldn't find anything existing in the forums or InMagic's website), but in order to do that I'm assuming I'll need the entire result set in XML before being able to manipulate it in XSL. Any ideas on where I can do this? I'm submitting my query via a HTML query screen, so I'm assuming there may be a variable I can pass on to tell WebPubPro to spit the lot out in a single hit. Any thoughts would be very welcome!

Cheers!

- Sean

if you pass the MR tag through with a number, it will set the number of records to be returned by WPP, the default is 1000

eg. From an html form:

<input type="hidden" id="MR" name="MR" value="250" />

have a look at the input schema for more details and other tags:
http://support.inmagic.com/Web/DBTWandWPPv11/InputSchemaWPP10_11.html

MR can govern the number of records return on the present request, but there is also TX, which specifies the total number of records returned by XML output. The TX default is 1000, and I generally set it to 0, meaning no max, as it can otherwise skew your impression of how many records were found by a given query. (E.g. A search on the sample cars database for all records should find 30, but when TX is set to 10, the queryCount is reported as 10: http://localhost/dbtw-wpd/exec/dbtwpub.dll?tn=cars&ac=q...all&xm=1&fn=/&tx=10).

It sounds like you're looking for info on how to page XML results without returning the entire result set and chopping it up yourself. This is possible.

Look up "Returning Records in Sets (XML)" in dbtext help. It describes how to set page size with MR and SP for the page you want. You first ask for n results and page 1. The Recordset node queryCount attribute in the output will tell you how many records have been found in total, the pageCount attribute tells you how many pages there are, and the page attribute tells you which page you're on. It's easy with this information to construct some paging logic.

Again, always set TX=0 when paging, else you may get misinformed about the total number of results available.

Thanks for your feedback and assistance guys, I'll give it a whirl on Monday probably - my arvo looks like it's going to be filled with other gear so I won't have time to play with XML until then. If I hit any brick walls, I might ask for some more assistance if that's ok

Cheers!!

- Sean

Hi again,

I've had a bit of a play around, and was hoping I could ask another question? Since I'm still learning I've had some issues with instituting paging logic, and have decided to try and mirror the 'Previous 20 records' / 'Next 20 records' kind of functionality you get with DBTW website reports.

I had two theories regarding this - the first one was that when the person clicked previous/next, it would perform the search again verbatim, but change the SP value (i.e. {inm:Results/inm:Recordset/@pageCount}+1). The problem was that I wasn't sure where I could grab the query info from, as when I looked at the raw XML output from a search, I could not find anything relating to the query itself in command mode, so unless there's a way to retrieve the query in command mode after the person has done a search and report it in XML so I can grab the element and slot it as a QY into the URL, I'm a bit stumped!

So, given that didn't work, I had a look at the source code when running a search on a DBTW form that has the 'next 20'/'previous 20' record buttons (20 being the default on any of my working textbases). I noticed that the URL had a stack of info encoded into it, and noticed that it used the AC=NEXT_BLOCK command, which I also looked up in the schema documentation. So, figuring this might be worth a shot, here's what I put together:

<a href="/dbtw-wpd/exec/dbtwpub.dll?AC=NEXT_BLOCK&TN=jfml&SN={inm:Results/inm:Recordset/@sn}&XM=1&TX=0&XS=test.xsl&XP=120&RF=Brief%20display&TI=0&MR=20&DL=0&RL=0&NP=3&CS=2">Next record</a>

Whenever I click the link, I get the response "Your current query has expired. Perform the search again.". I checked the settings in the .ini file, and maxstats was set to 2000, so I went back and tried to troubleshoot the URL. I put in AC=NEXT_BLOCK, and it said I needed to specify a textbase (d'uh!), so I specified my textbase (TN=jfml), and that's when it started putting the expiry error again, so that's where I've left it.

I tried experimenting with adding XP=120, but this didn't make a difference. Any chance someone could let me know what I'm doing wrong? Again, your help is very much appreciated!!

Cheers,

- Sean

NEXT_BLOCK is not really meant for use with XML results. I guess you could hack something together that worked (you need to supply SE as well as SN, plus RN for starting record number of previous set).

XML results are most useful in an environment where you want to bind results to controls programatically, which would also imply built-in techniques for maintaining state across posts - the search query, for instance. I'm wondering why you're taking on the headache of XML queries together with the back-pain of XSLT. Are you not able to achieve the same effects with HTML results?

Thanks again Peter for your help - I'll see what I can put together.

As for why I'm pursuing XML when it's obvious I'm having difficulty with it, I found that the forms designer in DBTW is woefully inadequate for giving control over html construction/design (and possibly compliance as well), as I want the search results to display neatly within our website's template and adhere to our established website styles. I managed to get it to work about 70% using SSI's, but there were still numerous broken elements that caused a number of issues. I notice that when there has been criticism of the forms designer and WebPubPro in these forums that InMagic's response has been "Use XML - it gives you full control over the results, etc", hence what I'm doing it. I currently have pretty much everything working very nicely within the design, including a few little things I wouldn't have thought of if I wasn't trawling through XSL code during this process, and this paging issue is (hopefully!) the last thing to challenge what will hopefully be a successful result! Well, finger's crossed!!

But yeah, that's my rationale. Again, thank you so much for your assistance in this, its greatly appreciated.

Cheers,

- Sean