OK. You found 801 entries  with ~200 k global  access.
and the query works as expected

So 

SELECT COUNT(*) 
FROM SQ.CBPhoneResult_View
WHERE PhoneDateODBC = '2018-04-10'

for Tuesday Apr.10 it should return 801  

What is the count for Monday  2018-04-09 ?  I 'd expect more

SELECT
 COUNT(*)
FROM SQ.CBPhoneResult_View
WHERE PhoneDateODBC = '2018-04-09' 

As you see the query plan is significantly shorter.
Your original refers to 3 other tables.
To find out why and how to improve would require all table/class  & view definitions

  • SQ.CBPhoneResult_View
  • SQ.CBPH_Phone
  • SQ. CBPH_Result      your 2nd query ends here  
  • SQ. CB_Test      access to  CallbackComment starts here
  • SQ. CB_Order
  • SQ. CB_Contact

Without the related class definition it is hard to say how these tables link to each other

But you really should run it from the terminal prompt to see your result at least once:

Do you have developer access to your Caché  at all? 
Can you see the class definitions in Studio ? 

OK,now your timeout is clear.
with a Relative Cost of  ~2 millions, your query requires some support to speed up.
You just see the first 6 empty results.

First reason: you run over ALL records in  ...PhoneMaster
with an inner loop in  ...Testmaster on IndexCall,OrdeCode, TestCode,...Result_Index

So your timeout is not surprising.

I'd suggest creating an Index on PhoneDateODBC to speed up your query. >>  lower  Relative Cost
with 2 million I'm quite sure that you even timeout over ODBC.

So I'm back to my earlier suggestion:
Let your query run from terminal prompt,
have a coffee or two and maybe it is completed then.

This is not your fault.
Blame the designer of that ugly VIEW

OK.
You use a Caché version before 2015.1 that doesn't know $TRANSLATE

It's then 

SELECT
 REPLACE(CallbackComment  ,'''','?')
FROM SQ.CBPhoneResult_View
WHERE PhoneDateODBC = '2018-04-09' 

I expect you will run into a timeout again.
So please click to "Show Query Plan" and let us see what's going on.

Additionally, on left border click to Views;
select  SQ.CBPhoneResult_View and get an Image similar to this

important part:  VIEW TEXT

OK. now the picture gets clear.

 the key problem looks as if a single ' is interpreted as a String delimiter.
so instead of naked CallbackComment 
You may try

$TRANSLATE(CallbackComment  ,'''','?')

(it's really 4single quotes, no typo)
So you replace the single quote by a non-conflicting character BEFORE the string is passed to ODBC   
This would prove that the single quote is the cause of trouble.

  • referring to CSP.... you  let me assume you are working from Mgmt Portal
  • next you say:  I am using the Intersystem ODBC driver

This is a contradiction  as CSP doesn't use ODBC driver
So what are you really assuming to do ??

Anyhow in both cases a SQL String delimiter (') entered in a %String property aka VARCHAR is always presented as it was entered.
I verified it over an external ODBC viewer +  Intersystem ODBC driver as well as over JDBC:  no issue.

For ODBC on Windows just use 64bit Version on 64bit platforms.

in addition, you may verify your query also from the terminal prompt without any eventual timeout:

USER>do $system.SQL.Shell()
SQL Command Line Shell
----------------------------------------------------
 
The command prefix is currently set to: <<nothing>>.
Enter q to quit, ? for help.
USER>>  << entering multiline statement mode >>
        1>>SELECT
        2>>CallbackComment
        3>>FROM SQ.CBPhoneResult_View Where PhoneDateODBC = '2018-04-09'
        4>>go

 

if you define a method   mymethod() as something

You are expected to terminate ist either by QUIT anyvalue  or  RETURN ayvalue

in your example you announce a %Status. so Quit $$$OK would be fine like this

ClassMethod getFile() as %Status
{
    set filename = "/home/test.json"
    set newArray={}.%FromJSON(filename)
    write "New entity:"_newArray.%ToJSON()
    quit $$$OK
    }

if you ommit  as %Status you can allso forget the ending QUIT

You are wrong:   getFile+8 is 

    set i2 = resultSet.rowSet.%GetIterator()


so either resultSet. or resultSet.rowSet is not what you expect it to be.

first you do 

set sc = stream.LinkToFile(filename)

 but you don't check the success code

And with "path/to/file.json" the file name looks more than suspicious to be correct.

next you do set obj=...   but this obj isn't used at all.

next 

set jsonObj = [].%FromJSON(filename)

and there is the fundamental mistake as your variable filename is

set filename = "path/to/file.json"


which is anything else than the expected JSON array

 you may have lost some important lines during cut/paste from your example

 Deserializing from JSON to a dynamic object may have important information for you

I try a simple explanation and you should try to find some docs on HTTP:
So I leave out several steps in between to illustrate the basic actions.

your browser sends a request

GET /index.html HTTP/1.1
Host: www.example.com

and if it is successful the server replies

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>


The highlighted part between HTTP and your first <html> is prepared or modified  if not default in OnPreHTTP().
It has to be ready BEFORE sending the reply. 

The delimiter between HTTP part and the content transmitted is just an empty line.
The closing is 2 empty lines.

For the items you can influence see class %CSP.Response

you do .ReadLineIntoStream()  
doc says: https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls

This reads from the stream until it find the LineTerminator and returns this as a stream. If the stream does not contain the line terminator this can potentially be the entire stream.

and your error message:  Premature end of data 12 Line 1 Offset 1     

indicates that you have hit some character interpreted as line terminator after 12 characters. (rather short for  JSON)
My guess: your JSON input is a multiline input with enough line terminators inside

As a consequence your JSON input is incomplete.

Suggested workaround

  • get length of your stream method SizeGet()
  • read full stream ignoring line terminators using method Read(ByRef len As %Integer, ByRef sc As %Status) as %CacheString

eventually, it might be necessary to remove the line terminators before  %FromJSON