First thing I'd double check because of the message you're receiving is if one of the records in these windows is locked and needs to be committed prior to another window acting on the same record. Occasionally, this message can also occur if a portal is being interacted with in multiple windows too.
Thanks Eric. appreciate your reply.
I don’t think is the records being exported thats the problem, I’ve just been exporting with the records sorted in different ways, but they always fail at the same window, irrespective of the records being saved.
I have the same problem if I’m exporting records from the different parts of the DB, i.e. the people records, although that might be because I’m using the same script!
I think I’ll sleep on it and try again tomorrow!
Then, it exports the top window to XML, ups the file counter to generate the next file name, (*) then closes that window, and repeats on the next active window and so on.
Insert a commit records/requests script step at (*)
Thanks Siplus, Ive tried the commit records but with no apparent change. I now think the problem starts a bit earlier.
I’ve been looking at the window_open subroutine this afternoon. That opens a new window, -2, which is a duplicate of the found set, so that the original found set is still there when the windows are closed after saving. It then loops, opens another window’, -3, removes the first 20 records, then opens other windows, -4, -5, etc, until the found set is less than 20 and then drops out of the loop.
Now, when the records are saved there seems to be no problem with windows -5, -4, -3, but the ‘ Can’t Modify’ warning pops up between -3 and -2. Maybe window -2 is the one too close to the original?
Need to do some more trials with different numbers of unmodified versions of window -2.
sometimes a pause/resume script (0 seconds) here and there works wonders. Gives time to plugins / different windows to answer "ok, I'm ready" to the main script that invoked them. Try that, too.
All this opening many windows is anyway less than efficient. A new / duplicate window carries with itself a lot of burden. There are other ways to do what you are trying to do.
For example, when you have a found set you also have a List of PK's. Via ESQL or via Summary List of (PK) or or.
now, armed with such a list, set a global gList to LeftValues(yourList; 20) and set the yourList to rightValues(ValueCount(yourList) - 20). Have a relationship gList -> yourDataPK and GTRR on it in a new window.
Process, close window, rinse and repeat.
In a nutshell, you have a global text field holding n-1 times 20 PKs and the nth times m PKs, m ≤ 20. You GTRR on that global, process the records, maybe pause/resume script, but only one additional window at a time.
Hopefully I made myself clear.
Thanks for the suggestions. I had put pauses in the script (though not systematically) as part of the debugging, didn’t seem to made much difference.
And as for rethinking it again as you you suggest, there are two problems. One, I haven’t got the time, I need to pass it over, and 2, I certainly haven’t the knowledge.
So, I’m going to abandon this route and go for a workaround. Custom dialogue box if export set >20, with options (and instructions) to go back and sort it manually before re-exporting in batches of <21. Should be easy with the drop-down list of recent finds now on the Status bar.
Many many thanks for your help and support, I do feel slightly better knowing others, more wise than I can’t sort it out.