I miss 3 things in this example:

• There is a condition: I found no IF nor anything
• at the end of the inner loop there is no CLOSE file1 7 /  CLOSE file2  for file1 or file2
• OPEN file:("WNS": ......)   
  • W - Write is ok
  • S - Stream mode is OK
  • N - i s questionable. if you are not on VMS you override the file at each outer loop
    http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GIOD_rmsseqfiles#GIOD_rmsseqfiles_use
    New file. If the specified file does not exist, the system creates the file. If the specified file already exists, the system creates a new one with the same name. The status of the old file depends on which operating system you are using. On UNIX® and Windows, Caché deletes the old file. (Note that file locking should be used to prevent two concurrent processes using this parameter from overwriting the same file.)

      So to get all output you may append arrayIndex to filename to have unique file names

My final idea:
- restart the whole ENSEMBLE instance to get rid of anything that might be hidden/hanging around in memory.
     It's not my preferred solution, but with the actual information, nothing else seems to work.
     If someone starts screaming you may have identified you opponent that blocks you. 
- if the problem persists further then contact WRC 

I did more research on %Studio.ProjectItem:

In the actual version there is no chance to such a lock situation.
Export is using a lot of  %Studio classes. So either a Studio instance or some other editing blocks something.

BTW: what version of ENSEMBLE do you use ?
 

From your screenshot, I see that you have a running production.

#1) ENSEMBLE has an internal locking not seen in LOCKTABLE.
#2) If you try to export the actual running production this might be you might get in conflict with this internal protection.

I found no note that you can't export a running production.
Though I've never heard of such attempt as a production consists many dynamic moving parts.

Suggestion: STOP the production you want to export and then try the export again.

Documento Nacional de Identidad (Spain)

https://en.wikipedia.org/wiki/Documento_Nacional_de_Identidad_(Spain)

The the description is somewhat vague:

Exclusive LOCK happens on process basis not by user !
It's not clear where you run "export from the production". Portal,Terminal, Studio, ...

if you are in Studio and run "export from the production" in MgmtPortal or Terminal then you have 2 processes.
1 has the lock the other can't get it.
 

take a look in MgmtPortal >  System Operation > Locks  > View Locks

Now you should see who is owning your lock 

Congratulations !   
let me have your accepted   

Cheers, Robert

BTW. Class %ZEN.Component.querySource  still does it as iit did in past.

For more tricky manipulation you have

/// (optional) Name of Server-side callback method to call to create
/// a <class>%ResultSet</class> object.<br>
/// This must be the name of a server-only method in the page
/// class that contains this component.
Property OnCreateResultSet As %ZEN.Datatype.delegator(FORMALSPEC = "*tSC:%Status,pInfo:%ZEN.Auxiliary.QueryInfo", RETURNTYPE = "%ResultSet");
/// (optional) Name of Server-side callback method to call to execute the
/// <class>%ResultSet</class> object.<br>
/// This must be the name of a server-only method in the page
/// class that contains this table pane.
Property OnExecuteResultSet As %ZEN.Datatype.delegator(FORMALSPEC = "pRS:%Library.ResultSet,*tSC:%Status,pInfo:%ZEN.Auxiliary.QueryInfo", RETURNTYPE = "%Boolean");
 

yeah, table navigators chop the original resultset.

but with the absolute rowID (%vid) and the pageSize (pS)  you should get pageNum= %vid\pS+1
and relative rowID= %vid#pS

Or directly in SQL  with pageSize = 12

you will keep the * away as you don't need the content

It's all based on the fact that the 'base'query always generates the same sequence of rows 
Just dynamic filters may break this. 
For paging also tablePane has to use the same mechanics. 
 

WOW!   good luck.
and let me have your Accepted  

doc for ORA-01861
describes the TO_Date issue very detailed

https://www.techonthenet.com/oracle/errors/ora01861.php

Your problem seems to be strictly related that the value you use and its description in TO_DATE don't match.

So TO_DATE(?,'YYYYMMDD') in Prepare
should work with 
    s result=obj.%Execute(20180425,par2,par3,par4)

It's a little bit less transformations

Oops. we overlapped. pls. take a look to status

Through terminal couldn't make it work no mater what i tried, not when it is %Date and using $h without to_date nor when it is %String and translating the date to yyyy-mm-dd with or without to_date (at prepare or at execute).

Did you also try SQL shell from terminal ?  (it should act like SMP)
SAMPLES>Do $system.SQL.Shell()
SAMPLES>>INSERT INTO .......

Also: have you ever checked status  ?   to see if  %Prepare was OK ?

after:

s status=obj.%Prepare(statement)

do $system.OBJ.DisplayError(status)
It's hidden in your example

ok

did you try '2018-04-23' instead of $h ?

SELECT top 3 EFFECTIVE_START_DATE PACKAGE.SOME_TABLE_NAME

may show the expected default.

you didn't get me. The browsers make something unreadable and useless out of it.
That's just rubbish

 ?Á
Â0 
?_eä,cÒ
'=
*^<YÙF¡í$í¼ÈÞÝt 
oÉ÷ý$?|
¤1¡{Dâhà°Ý?Öù)2ós??R?¸¼?ºd?$,ñD+»??
? 
ÔºQZéýNÕ V{C?óò?b¢?éÍ )$ 
²5Å?wEë? ??©tÖã1z×2FëÊnôeË æ??]Zßq ܺ?á

pls do:

So we see the real HEX_content , eventual control characters, ...  and the received number of characters
Similar to your request the response is encrypted. Eventually,  it can be decoded. 

where does Answer in Ensemble: come from ??

pls add:
write tHttpResponse.Data.Size,!

ZZDUMP tText

WOW !   

I had that feeling that it might be more.
And took a look to  ##class(%ZEN.Auxiliary.jsonProvider).%WriteJSONStreamFromObject() as it is visible.

It's nothing I would like nor to touch nor ever to maintain over future releases in parallel to ISC.