go to post Kevin McGinn · Nov 1, 2021 I appreciate the further edification on the management of the cache database; it will be useful going forward.
go to post Kevin McGinn · Oct 25, 2021 That makes sense. At any point I can manually reset the current size to a size less than or equal to the max size. But if I, at some point, reset the current size, cache will still attempt to allocate the space when this size I set is consumed. I believe this is correct. So, essentially I can manually intervene with the space allocation process but the automated space allocation process is still in place.
go to post Kevin McGinn · Oct 8, 2021 Intersystems continues to request a conclusion to this issue. I have already stated and included such. So this will be redundant. I worked with support, copied a cache.dat from another system of the same version to correct the issue.
go to post Kevin McGinn · Sep 28, 2021 Per WRC. 2 possible fixes: 1). perform a install/repair, or 2). work with WRC to determine if the corruption is fixable.
go to post Kevin McGinn · Sep 24, 2021 Ok, so there isn't a problem with defining the static variable once as is proper design. based upon your response, I found the root cause of my issue. My static variable is a 600 char. string. This apparently exceeds the 'send:' buffer of the terminal script file. I broke the variable into 3 send: statements of 250, 250 and 100 chars in length the last send followed with a <CR>. The script functions without issue now.
go to post Kevin McGinn · Sep 22, 2021 SOLVED The fix is to break the write statement into multiple 'send:' statements with the last send containing the trailing <CR>. So my write statement becomes: send: WHILE rset.%Next() { set sub=$PIECE(rset.%Get("CurrentDevice"),"|",2) set devLen=$LENGTH(rset.%Get("CurrentDevice"),"|") set port=$PIECE(rset.%Get("CurrentDevice"),"|",3) set dev=rset.%Get("CurrentDevice") set IP=rset.%Get("ClientIPAddress") Write rset.%Get("jobNumber"),",", rset.%Get("Pid"),",",rset.%Get("UserName"),",",$CASE( devLen,1:"null",3:dev,4:"|"_sub_"|"_IP_"|"_port),",",rset.%Get("NameSpace"),",",rset.%Get("Routine"),",",rset.%Get("CommandsExecuted"),",",rset.%Get("GlobalReferences"),",", send: rset.%Get("State"),!} <CR>
go to post Kevin McGinn · Sep 22, 2021 The real issue is that the query and result processing functions without issue in an interactive term session. But when passed as a term script to a batch term session the result processing is ignored. Because of this I know there are no real issues with the statement; just confused why there is an issue in the batch mode.
go to post Kevin McGinn · Sep 8, 2021 After much discussion with Intersystems support the root cause of this error was/is that the cache.dat associated with the SYS namespace is missing. Review of system and cache logs does not give a clear indication as to how or when this occurred. Following the supprt guidance, we have a near identical system ( identical cache version) so we can copy that cache.dat file. Per support, there will be some things to correct but that will get our system back up.
go to post Kevin McGinn · Sep 3, 2021 I appreciate the feedback from the many respondents. To answer the question posed by the responses: 1) I did try zn "%SYS" this produces the response ZN "%SYS"^<DIRECTORY> */cachesys/mgr/<DIRECTORY> */cachesys/mgr/ which I take as it is not comprehending the command 2). The last command before this issue. I wanted to get db information using the $zu(49) which I then found has been deprecated. The $zu() method is new to me but there is documentation (apparently old) describing its utility to get information on a db. 3). As a database consultant we, unfortunately, only have a single sets of creds to access the server. Because of this I don't have the option to determine if the issue is isolated to my creds.
go to post Kevin McGinn · Mar 5, 2020 I am running this script on a Windows box. The Cos script file was written using notepad++. Because of this the file had windows line terminators. The Fix: I updated the file replacing the Windows linefeeds with unix line feeds. The script functions perfectly now. Thank-you for the help.
go to post Kevin McGinn · Feb 27, 2020 Eduard Lebedyuk; thank-you for your help. Unfortunately, switching to IRIS is not an option as we are preparing to support clients who are not prepared to upgrade to IRIS; at least not yet. I will, though, look at PythonGateway. Again, thank-you for the help. Kevin McGinn
go to post Kevin McGinn · Feb 27, 2020 "select 1" generates the same error: tHdl.prepare(sql)intersys.pythonbind3.cache_exception: file=intersys/pythonbind3.c line=3355 err=-1 message=cbind_prepare_gen_query() What is more perplexing is if I create a python script using an ODBC connection instead of pythonbind3, the select does work. But I prefer not to use ODBC.
go to post Kevin McGinn · Feb 27, 2020 I added the import of the traceback lib as you suggested. Putting the traceback statement after the execute or fetch caused an error stating that "last_type" does not exist which would I should see if no errors were found (as I understand it) . I changed the select to "select * ....." and that produced the error: File "getTables.py", line 45, in main tHdl.prepare(sql)intersys.pythonbind3.cache_exception: file=intersys/pythonbind3.c line=3355 err=-1 message=cbind_prepare_gen_query() an even more confusing error for which I have not found any info on the error condition. I changed the the statement to "select count(*)...." that was a mistake. The python script never returned.
