Thanks for the clarification.
It's sometimes hard to guess the picture if you miss some pixels.
I'd still recommend moving the CLOSE after each inner loop to have OPEN / CLOSE strictly paired
The implicit CLOSE happens only if you exit the partition. There's no class to act undercover.
Curly braces just structure the code with no operational side effect.
Happy I could help. 
It seems you have manually changed the class definition.
A normal RegisterdObject has no storage definition.
from <Type>%Library.CacheStorage</Type> i see it was a %Rersitent before.
remove Storage and recompile.
I finally succeeded in reproducing your error
ERROR #5803: Failed to acquire exclusive lock on instance of '%Studio.ProjectItem'
The conditions are somewhat strange and you should take an exact check what applies in your case.
The story:
So try to find out in Terminal
Look if you see oddPROJECT
Next try to estimate the number of items your production will export.
If you get close to the dimension of xxxxxx then you run most likely into your error.
Be aware that some components can create more than 1 entry. So your limit might be lower (70% ??)
You can increase the threshold in
MgmtPortal > System Admin > Configuration > SQL and Object Settings > General SQL Settings
ATTENTION: If you set this value to high you risk an overrun of the LOCKTABLE.
This blocks the whole instance. Increasing the size of LOCKTABLE + Restart is then required. Or you set the limit t back.
I miss 3 things in this example:
So to get all output you may append arrayIndex to filename to have unique file names
where do you hoover ? SMP, Studio, Atelier ?
as you noted SEEMS not to work.
method OnInit() as %Status
This user callback method is called via initConfig() from %OnNew() or in the case of SOAP Services from OnPreSOAP()
$$$LOGINFO("INIT") translates to
I'd suggest to replace it by set ^Antonio($i(^Antonio))=$lb($ZDT($h,3),"INIT")
so so find out if your Init gets called or not or multiple times, ..
Especially during init phase high independence from the rest could be useful
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)
Salva, that's Great!
without having to change the class definition
I like this.
Robert
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
/// 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.
Hi Chip,
If I understand it correct you have a value and look for the related rowID in your tablePane.
tablePanes get typically feeded by a well know SQL SELECT and it numbers its rows sequentially.
For ease of explanation, I use SELECT name,home_city TOWN FROM Sample.Person to fill your tablePane
Let's look for TOWN = 'Denver'
Of course, there is still arithmetic required if you have several sections to calculate.
This just gives you the 'absolute' rowID, not the relative.
HTH, Robert
the DSN is used when you set up your SQLgateway connection.
MgmtPortal > System > Configuration > SQL Gateway Connections
There all information on the DSN is stored.
Next if you Link the external table this gateway entry is used and stored for access.
MgmtPortal > System Explorer > SQL > Wizards > LinkTable
Now you bind a Class in a Namespace to a Gateway to a DSN
So you are fixed for THIS namespace. This is static.
If you change the Gateway entry or the DSN in some essential way
it could happen that you have to do this again.
Similar for a different target table you have to do the Link again.
A different issue could be that you might just have read access to the foreign table.
Then I'd expect some kind of error message.
At least it is something the partner side has to manage.
so either you or someone else just has it opened in a different Studio / Session.
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
Last hint in prev. thread was:
Contact WRC as 2008 is pretty aged.
https://community.intersystems.com/post/cache-compile-problem
last comment:
https://community.intersystems.com/post/cache-compile-problem#comment-48466
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.
The change from %Date to %String influences image of your target table
and may affect implicit ODBC Data transmission that converts eg. +$h to YYY-MM-DD format !
once your data is a %Date again this should do it:
...... VALUES (?,?,?,?)
%Execute($zdh(somedateYYYYMMDD,8),par2,par3,par4)
If you test in SMP you have to check if you are in ODBC, Logical or Display mode.
with TO_DATE() you just overrule this as string are the same in any mode.
For ODBC the date is always 2018-04-25
For Display it's 04/23/2018 or 23.04.2018 depending on your local setting
For Logial it is always 64761 (+$h)
OK.
you got a reply of 149 characters!
And what was the result of ZZDUMP tText?
It should look similar to this:
I filled in the marked characters to get to your received size. The real value could help as there is a bunch of controls that could trigger a newline.
The thing looks somehow encoded / encrypted or just binary.
Do you have information on source system ? (the url is definitely faked)
Classes and Methods forever!
#1) for documentation
#2) for all the possibilities and structural controls of OO development.
#3)
.mac & .int is a left over from a previous millennium,
a (failing) attempt to mimic OO with the mindset of procedural methodology.
I'm personally disappointed that Atelier still supports mac.
It was a historical requirement. Accepted. For last millennium. Eventually still for some internals.
Definitely not for public use.
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