Is there any way to see the size of a variable (char, int, handle, etc...) in bytes?
We have a couple of problems where our code seems to send more information from the client to the server when opening a query (which is obviously wrong) and I'm trying to see where this could be occurring.
Thanks
Oliver
In a word "no".
Can you describe what it is that you think is happening in more detail? (It doesn't sound obviously wrong to me.) And maybe explain why knowing how many bytes (on disk?) a variable is taking would be useful?
TBH I'm rreally just clutching at straws trying to find what is happenning.
The program in question is an order enquiry and is written in 2 parts.
The first part is a small lookup screen to find the order and account details.
Once you have found the order you press OK and then the server sends down the information about the order. It is at this point that a LOT of data is sent from the client to the server. I'm trying to analyse what is going on in order to cause this.
At first I thought it might be temp-tables being passed to the server but there aren't any. All the app server calls take string/int/handle inputs.
Apart from these there are really no other data passed from the client to the server.
Thanks for any help/advice/tips.
Oliver
Are you using an AppServer? The server and broker log files with the highest logging level (4) report the bytes received and bytes send.
I find that quite informative when finetuning temp-tables passed back and forth.
AppServer server logging set to ASPlumbing Extended
[09/06/16@14:06:37.459+0200] P-006440 T-006436 4 AS AS -- TRACE: Open4GLWriteLast 5805. (8401)
[09/06/16@14:06:37.459+0200] P-006440 T-006436 4 AS AS -- TRACE: Open4GLWrite 5805. (8402)
[09/06/16@14:06:37.464+0200] P-006440 T-006436 4 AS AS -- TRACE: cso4GL: Before loadProc() (8458)
[09/06/16@14:06:37.464+0200] P-006440 T-006436 2 AS AS -- TRACE: Non-PERSISTENT Procedure 'ry/app/rygetmensp.p' START. (5498)
[09/06/16@14:06:37.466+0200] P-006440 T-006436 4 AS AS -- TRACE: cso4GL: After successfull loadProc() (8458)
[09/06/16@14:06:37.466+0200] P-006440 T-006436 4 AS AS -- TRACE: Set open 4GL server state to 8. (8400)
[09/06/16@14:06:37.466+0200] P-006440 T-006436 4 AS AS -- TRACE: Set open 4GL server state to 2. (8400)
[09/06/16@14:06:37.466+0200] P-006440 T-006436 4 AS AS Server Message state = MSGSTATE_SENDRESP
[09/06/16@14:06:37.466+0200] P-006440 T-006436 4 AS AS -- TRACE: cso4GL: In execProc() - before execution. (8458)
[09/06/16@14:06:37.526+0200] P-006440 T-006436 3 AS AS -- TRACE: Non-PERSISTENT Procedure END SUCCESS. (8397)
[09/06/16@14:06:37.526+0200] P-006440 T-006436 4 AS AS -- TRACE: cso4GL: In execProc() - successful execution. (8458)
[09/06/16@14:06:37.526+0200] P-006440 T-006436 4 AS AS -- TRACE: cso4GL: In execCall() - execProc() success. (8458)
[09/06/16@14:06:37.526+0200] P-006440 T-006436 4 AS AS -- TRACE: Set open 4GL server state to 3. (8400)
[09/06/16@14:06:37.526+0200] P-006440 T-006436 4 AS AS -- TRACE: Set open 4GL server state to 13. (8400)
[09/06/16@14:06:37.527+0200] P-006440 T-006436 4 AS AS -- TRACE: open4GLRead 8192. (8403)
[09/06/16@14:06:37.528+0200] P-006440 T-006436 4 AS AS -- TRACE: open4GLRead 8192. (8403)
[09/06/16@14:06:37.528+0200] P-006440 T-006436 4 AS AS -- TRACE: open4GLRead 8192. (8403)
[09/06/16@14:06:37.529+0200] P-006440 T-006436 4 AS AS -- TRACE: Set open 4GL server state to 1. (8400)
[09/06/16@14:06:37.530+0200] P-006440 T-006436 4 AS AS -- TRACE: open4GLRead 3154. (8403)
From my observation this means, the request had 5805 bytes (which may include temp-table schema) and the response took 3 * 8k + 3154 bytes (which may also include temp-table schema).
> All the app server calls take string/int/handle inputs.
Strings are easy -- just use the LENGTH() function. Integers are messy but if you just assume 4 bytes each that is probably "close enough". Handles are not so easy or so obvious, IIRC it is possible to get a "deep copy" when you think you're just passing a pointer. That might be your problem. A code snippet would probably help people to better analyze what is going on.
Never mind, will send it tomorrw.
Sorry abou that post.
I put a load of info up but realised it wasn't correct and then couldn't find the delete post button.
I think I've found the problem though.
Everytime the appserver is called the client sends down the schema details of all the temp tables to the app server. This means that for this particular query there is 200kb+ sent to the server and only 70kb received. (I've been watching it with Wireshark to analyse what's going on).
So, now all I need to do is find a way to stop the schema details being sent down the line every time we go to the app server.
You may want to try various settings of the SCHEMA-MARSHAL attribute of the Temp-Table object handle.
Nachricht geändert durch Mike Fechner
We have just found that somehow, in our latest release, the start up file has had ttmarshal and mc parameters removed from it.
Put them back on and the client upload went from 200KB (for one query) to 9KB for the same query
Thanks for the help everyone!