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
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 ?
You may also reformulate your SELECT to read directly from the tables used
starting with the one holding PhoneDateODBC and forget all the other burden.
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.
what product/component are you interested in?
and others is as wide as the whole software industry
please be more specific
in addition, it would be worth to see what your SQ.CBPhoneResult_View does.
By the ending VIEW I assume it is a View and not a Table:
So the complexity of the executed query is hidden and could be the real performance problem.
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:
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
so either resultSet. or resultSet.rowSet is not what you expect it to be.
first you do
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
and there is the fundamental mistake as your variable filename is
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
It means in row 8 of method getFile you try to use some object reference that doesn't exist yet or is not initialized yet.
posting some of your code could enable more precise diagnostic
Hi Scott,
It's indeed surprising.
But digging into docs tells me>>>> it's not an ERROR code but a RESULT code and 0 = Success. (like SQL)
more LDAP Result Codes
Err2String is defintely a misleading naming.
It could be sufficient to set ID=""
at the beginning of your code to avoid the <UNDEFINED> later down.
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
Analysing your code I found @ line 24
ending @ line 42 that contains
but i didn't see an ELSE if the first IF fails.
Then LD is undefined.
I'm a little bit surprised how it could go up to line 104
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
eventually, it might be necessary to remove the line terminators before %FromJSON
with large numbers exceeding 64bit integers the logic with integer division \ and modulo #
was causing wrong results. So I changed it to pure string interpretation.
Recommendation:
pass all numbers as strings to escape from numeric normalization
NOT write $$^zahl(102100900002103201200301.6123100)einhundertzwei Trilliarden einhundert Trillionen neunhundert Billiarden zwei Billionen einhundertdrei Milliarden zweihundertein Millionen zweihundert Tausend
BUT write $$^zahl("102100900002103201200301.6123100")
einhundertzwei Trilliarden einhundert Trillionen neunhundert Billiarden zwei Billionen einhundertdrei Milliarden zweihundertein Millionen zweihundert Tausend dreihunderteins Komma sechs eins zwei drei eins null null
If you feel think this is exaggerated think about banking calculations for countries within low rated currencies.
You are right.
Though due to the internal limits, next time I would avoid \ and # operations in favor of $E() for the next version
As there are some strange effects in handling numerics due to normalization
Hola Francisco,
You motivated me to do something similar for German.
It's is straightforward .int routine and you are welcome to add the code to your project.
GermanNumberToText
I did it up to 10e21, negatives and unlimited decimals. (except what is cut down due to internal limits)
I tried to catch all the irregular structures of the language like singular/plural, varying genders, upper/lower case
and tried to keep the output readable:
For quick copy:
Updated to avoid failover from integer to floating format for large numbers (2018-06-28 16:34 UTC)
Before dealing with adapters you should check if your UDP reaches your server at all.
You always get it if your server is on the same LAN segment as the sender.
But you depend on the setup of the router in the case that it is not in your LAN "neighborhood".
2nd your firewall should be willing to let pass this UDP.
Then you may check the traffic with some external tool to make it visible.
Or you check it directly from terminal following the instructions in IO device guide
chapter UDP Client/Server Communication
you have the option to read by character using
READ *var
Then you read exactly 1 byte in its decimal representation
Docs on READ
You may also use %File Class and use a Read method with length 1
Use $ZCVT() function for decoding,
set y="<html><body><h1>Greater = > lower 0= < Ampersand = & OK</h1></body></html>"
write $zcvt(y,"I","HTML")
<html><body><h1>greater = > lower 0= < Ampersand = & OK</h1></body></html>
Attention all &..; have to be in lower case
See doc $ZCONVERT()
2 possible solutions:
see also my article Summary on Local Variable Scoping
Full doc is here :
https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?APP=1&LIBRARY=%25SYS&CLASSNAME=%25Library.File
Method CopyFile:
https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.File#METHOD_CopyFile
Vitaliy,
That's excellent. I had the vague feeling that it should be somewhere, somehow, ... ass these are all supported collations.
Now I have the correct solution!
Many thanks !
You can also create your own conversion function like this:
Then you simply use
SELECT SQL.fromUTC(CreationTime) FROM Table
to get the conversion
You try to upload a file and JS Code a the same time during your SUBMIT action.
so your &js< ...> lands every 32000 characters inside your file.
&js<..> is just a hidden WRITE and allows javascript syntax checking inside the <.. >
example:
is identic to
So your concept doesn't work that way
You would require a second independent JS routine in a browser to call for progress using CSP hyperevent.
Oh dear, NO MORE LICENSES.
Then inconsistency is clear!