chooseWindow question

[hpesata]

Hi!

I am calling a Calgary Scripted Webservice via an C# SOAP client to query several tables of our SN instance.

Because of the size of the tables I splitted the SOAP-calls by using chooseWindow() within the webservice.

the code in the webservice looks somehow like this, the new "window-begin" is a parameter used by the SOAP-client in my specific case:

var sysids = [];

var begin = 0;

var windowsize = 1000;

var done = false;

while(!done) {

  var gr = new GlideRecord('label_history');

  gr.orderBy('sys_id');

  gr.chooseWindow(begin, begin+windowsize);

  gr.query();

  if(gr.next()) {

      while(gr.next()) {

          sysids.push(gr.sys_id.toString());

      }

      begin += windowsize;

  } else {

      done = true;

  }

}

my result-rows are packed into JSON structures and returned to the client.

I realized, that sometimes I am receiving duplicate rows between the chooseWindow calls (usually the last row of the previous call is transferred again as first row of the new call) and I am wondering how this can happen ?

Maybe this happens beacuse of the insertion of new rows between the SOAP calls ?

Any suggestions would be greatly appreciated!

Thanx in advance,

Hans

[Ravish Shetty]

This questions was asked 2 months back, so did you get any solution?

If not then i am getting a feeling that "if(gr.next()) {" is the culprit, check the modification at line 12.

Please check if this works.

var sysids = [];

var begin = 0;

var windowsize = 1000;

var done = false;





while (!done) {

       var gr = new GlideRecord('label_history');

       gr.orderBy('sys_id');

       gr.chooseWindow(begin, begin + windowsize);

       gr.query();

       if (gr.getRowCount() > 0) {

               while (gr.next()) {

                       sysids.push(gr.sys_id.toString());

               }

               begin += windowsize;

       } else {

               done = true;

       }

}

P.S: "getRowCount" is not advisable if we consider its performance.

[hpesata]

Hi!

I think the problem is, that if You query the data of a big table with this approach (incident), it takes pretty long and

in between two window queries, new records get inserted, possibly within the new window and therefore the same sys_id is encountered again. maybe using the created-timestamp for the orderBy() clause would be a better approach.

regards,

Hans