[Isomorphic]

Are you using the Developer Tools that come with the browser or not? Looking in the RPC Tab of the SmartGWT Developer Console would not be correct. This is a totally garbled response and would not appear there at all.

What do you mean by "all of the SmartGWT responses before and after that one" - before and after which one?

[ecruz]

Sorry, I forgot to mention that

Yes, I was using the developer toolkit in IE10, not the RPC Tab in the developer console. There are actually multiple request/response entries there for other fetches and updates that we are doing before and after the call to the data source that correlates to the code snippet. I review all of those responses for having well-formed JSON, and they seemed OK.

[Isomorphic]

We're confused now.

There's just this one call that's failing, and you've shown us part of the log from the Developer Console, and it shows something clearly malformed.

But you're also saying you're looking at the response and it's fine.

What happens if you enable DEBUG-level logging for RPCManager and look at the SmartGWT Developer Console? This should show the full text of the response in a log that starts "Result string for transaction #: ...".

[ecruz]

Sorry for the confusion...

I am out of my depth a bit here, but hopefully I can clarify what is happening. The uncaught exception shows the response.getData() line to be the last line of our code that is executed in the stack trace. It's part of a fetch on a specific data source, and the response from the IE Data Toolkit that I posted originally is the only one that matches that same data source, so I assume it must be related to that code.

Earlier you had mentioned that the exception may (or must) have been caused by a different malformed response, so I just went through all of them to see if I could find one that was the culprit. This is all happening as we are loading are app, so there aren't that many to go through, about 15 altogether. All the JSON appeared OK with the other responses.

As far as the response being (obviously) malformed, you were referring to the //iscRPC... part, is that right? I just want to make sure I understand, because that part is also present on all the other responses as they appear in the IE developer toolkit, and in the one JSON response that works (ie, no uncaught exception) when I use a different DB, but the same code/same table in that DB.

I will look at the developer console next and let you know what I find.

Thanks very much for all your help and attention to this issue. Sorry for the learning curve involved.

[ecruz]

Here is the info from the developer console

21:02:13.350:TMR9:DEBUG:RPCManager:Result string for transaction 11: "//isc_RPCResponseStart-->[{data:[{CQST21:"T",CQS147:"N",CQST22:"N",CQS146:"N",CQS145:"N",CQST20:"N",CQS144:"N",CQS143:"N",CQS142:"N",CQS141:"N",CQS140:false,CSKU:3938,"CAL#":0,CQST29:true,CQST28:"*",CQST27:true,CQST26:"",CQST25:"N",CQST24:"N",CQS148:"N",CQST23:true,CQS149:"N",CQST30:"Y",CQS134:false,CQST31:"N",CQS133:"4",CQST32:false,CQS136:false,CQST33:"Y",CQS135:false,CQS130:true,CQS132:"4",CQS131:false,"CCC#":200000870,CQST39:"Y",CQST38:true,CQST35:"Y",CQS137:true,CQST34:"Y",CQS138:true,CQST37:true,CQS139:"N",CQST36:"N",CQS165:"N",CQS164:"N",CCUF:"0",CQS163:"N",CQS162:"N",CQS169:"N",CQS168:"N",CQS167:"N",CQS166:"N",CQS161:"N",CQS160:"N",CDDC1:1,CQST09:"Y",CQST04:"Y",CQST03:true,CQST02:"Y",CQST01:"N",CQST08:"N",CQST07:"Y",CQST06:false,CQST05:"0",CQS152:"N",CQS151:"N",CQS154:"N",CQS153:"N",ipmsRelease:3.3,CQS156:"N",CQS155:"N",CQST10:"Y",CQS158:"N",CQST11:"N",CQS157:"N",CQS150:"N",CQST13:"Y",CQS159:"N",CQST12:"N",CQST15:"N",CSYS:0,CQST14:"N",CQST17:"Y",CQST16:false,CDST:"","CCU#":4,CQST19:"Y",CTZC:"05",CQST18:true,CMRI:Date.parseServerDate(2012,0,24),CQS102:true,CQS103:true,CQS100:true,CQS101:true,CQS109:"2","CSH#":39,CQS108:true,CQS107:"9",CQS106:true,CQS105:true,CXID:"0","CFD#":18,CMRD:120124,CFFM:"01","CDR#":0,CQS120:"Y",CQS121:"N",CQS124:"4",CQS125:false,CQS122:true,CQS123:"N",CQS129:"I",CQS128:true,CQS127:false,CQS126:true,CCPR:9,CQS110:"2",CQS111:false,CQS112:true,CQS113:"M",CQS114:false,CQS116:"S",CQS115:false,CQS118:"N","C#FS":12,CQS117:true,CQS119:"R","CPO#":"0000000922","CCA#":12,"CPA#":0,CPOM:165,"C#6#":"","CRP#":928,"C#5#":0,"CSE#":0,CQS200:"N","C#CC":9,"C#4#":0,CQST98:"C",CQST99:"2","CRT#":16,CQST96:"Y",CQST97:"6",CQST94:"N",CQST95:"Y",CQST92:"C",CQST93:true,CQST90:"6",CQST91:"6","C###":"101025","CSR#":0,"CRC#":39,CQST89:"6",CNAM:"I3 3.3 QA MULTICURRENCY","C##1":""
21:02:13.362:TMR9:WARN:RPCManager:Error evaling structured RPC response: Syntax error response text: //isc_RPCResponseStart-->
21:02:13.390:TMR9:INFO:RPCManager:rpcResponse(unstructured) results -->"//isc_RPCResponseStart-->[{data:[{CQST21:"T",CQS147:"N",CQST22:"N",CQS146:"N",CQS145:"N",CQST20:"N",CQS144:"N",CQS143:"N",CQS142:"N",CQS141:"N",CQS140:false,CSKU:3938,"CAL#":0,CQST29:true,CQST28:"*",CQST27:true,CQST26:"",CQST25:"N",CQST24:"N",CQS148:"N",CQST23:true,CQS149:"N",CQST30:"Y",CQS134:false,CQST31:"N",CQS133:"4",CQST32:false,CQS136:false,CQST33:"Y",CQS135:false,CQS130:true,CQS132:"4",CQS131:false,"CCC#":200000870,CQST39:"Y",CQST38:true,CQST35:"Y",CQS137:true,CQST34:"Y",CQS138:true,CQST37:true,CQS139:"N",CQST36:"N",CQS165:"N",CQS164:"N",CCUF:"0",CQS163:"N",CQS162:"N",CQS169:"N",CQS168:"N",CQS167:"N",CQS166:"N",CQS161:"N",CQS160:"N",CDDC1:1,CQST09:"Y",CQST04:"Y",CQST03:true,CQST02:"Y",CQST01:"N",CQST08:"N",CQST07:"Y",CQST06:false,CQST05:"0",CQS152:"N",CQS151:"N",CQS154:"N",CQS153:"N",ipmsRelease:3.3,CQS156:"N",CQS155:"N",CQST10:"Y",CQS158:"N",CQST11:"N",CQS157:"N",CQS150:"N",CQST13:"Y",CQS159:"N",CQST12:"N",CQST15:"N",CSYS:0,CQST14:"N",CQST17:"Y",CQST16:false,CDST:"","CCU#":4,CQST19:"Y",CTZC:"05",CQST18:true,CMRI:Date.parseServerDate(2012,0,24),CQS102:true,CQS103:true,CQS100:true,CQS101:true,CQS109:"2","CSH#":39,CQS108:true,CQS107:"9",CQS106:true,CQS105:true,CXID:"0","CFD#":18,CMRD:120124,CFFM:"01","CDR#":0,CQS120:"Y",CQS121:"N",CQS124:"4",CQS125:false,CQS122:true,CQS123:"N",CQS129:"I",CQS128:true,CQS127:false,CQS126:true,CCPR:9,CQS110:"2",CQS111:false,CQS112:true,CQS113:"M",CQS114:false,CQS116:"S",CQS115:false,CQS118:"N","C#FS":12,CQS117:true,CQS119:"R","CPO#":"0000000922","CCA#":12,"CPA#":0,CPOM:165,"C#6#":"","CRP#":928,"C#5#":0,"CSE#":0,CQS200:"N","C#CC":9,"C#4#":0,CQST98:"C",CQST99:"2","CRT#":16,CQST96:"Y",CQST97:"6",CQST94:"N",CQST95:"Y",CQST92:"C",CQST93:true,CQST90:"6",CQST91:"6","C###":"101025","CSR#":0,"CRC#":39,CQST89:"6",CNAM:"I3 3.3 QA MULTICURRENCY","C##1":""<--

[Isomorphic]

So, very obvious issues here:

1. it's truncated

2. even if it weren't, it wouldn't be valid JSON (note Date.parseServerDate - that's not supposed to be there in a strict JSON response).

You've said several times that all the responses you can see in IE's Developer Tools are fine. So is this response just not there?

As far as how you got this invalid respond to be generated - once again it suggests some kind of issue in your code related to threading. Possibly you are holding onto a JSTranslater object and using it in multiple threads?

[jvopni]

Was there any resolution on this thread?

We have just run into this exact error. Symptoms are the same with it only occurring with any version of IE and with Oracle database backend. Doesn't occur if using SQLServer or if using Chrome/FF with Oracle.

Currently testing with latest build 4.0p build. SmartClient version 'v9.0p_2014-03-11/PowerEdition Deployment'

In troubleshooting this issue I was able to get the problem to disappear if one of my return attributes was NULL in the database causing it not to appear in the JSON string. I did a diff between the good and bad response strings captured with IE Developer Tools and the only difference was
,"dev_sdkapp_names":"x"
was in the bad response.
The ds.xml for this attribute is just
<field name="dev_sdkapp_names" type="text" > </field>

This issue makes no sense to us as to why the DB backend would make a difference. We do notice that there are differences with the json strings returned if client is IE vs Chrome. I am going to see if there is any difference in the response strings if the db is Oracle vs SQLServer.
Any suggestions would be appreciated on how to proceed with troubleshooting this problem.

[Isomorphic]

There was no resolution on this thread as far as we're concerned - it ends with Isomorphic being provided diagnostic information that clearly does not match the claimed behaviors.

Your problem doesn't actually seem to be related in any way except that it's odd and it involves IE, so you may want to start a new thread, as this one is full of noise.

Note that we do provide different responses to IE vs all other browsers. This is required because Microsoft broke JavaScript eval() in IE9 then claimed it was "by design", requiring us to build a slower, less flexible parallel comm system for IE.

[jvopni]

Ok.. will open a new thread after a bit more investigation.

[Isomorphic]

OK good. In the new thread, please be sure to post the server response in the working and non-working cases, and what error is reported on the client.

Also, since you seemingly identified the only difference in the response as being a property "dev_sdkapp_names", we would try renaming that property. Maybe you have some plugins installed in IE, or some security software between the browser and server, that is reacting specially because of that particular string in the response.

[jvopni]

I don't need to open a new thread. I was able to track down our problem (after much head banging)

The problem is with Oracle. The data being returned by the SQL statement was wrong. Oracle has a bug with the LISTAGG function when used with a NVARCHAR2 field. The data being returned was declared as a NVARCHAR2 field but it was sending data which looked like is was separated by spaces but in fact it was 0x00 chars. So the data was actually being passed back was not just "x" but rather with a 0x00 in front of the x.
The DeveloperTools in IE parsed this data and just skipped these nulls when showing in the Network tab. The IE JSON parser didn't like these extra nulls.

Both Chrome and FF just handled these by skipping over them.

I was able to change the underlying VIEW and the problem disappeared.

Lesson: Don't trust what you see formatted in the browser tools. A wireshark trace between machines showed me the real issue.

[Isomorphic]

Thanks for letting us know.

Wireshark is definitely an excellent tool :)