Hi Robert,
The process is updating records, not queries or select statements. It's taking a record set from one file and issuing UPDATE statements against another table.
If it's a pure update/insert process without any selects involved, there are fewer performance factors in play. The write speed on the database server primarily depends on the CPU/cache speed, followed by the speed of the disk holding the transaction log, and speed of the disk holding the database file. The write speed of the database client depends on the insert method used (prepared statement vs direct execution, with or without a cursor, single vs wide insert, imported from a client file or direct supplied data, etc.), network latency, and the client performance information (i.e. how busy is the client doing other work?).
Raw (maximum) database client insert times against the database server can be calculated via the \Samples\SQLAnywhere\PerformanceInsert\instest.exe ESQL test program:
Usage: INSTEST [options] [fname]
Options:
-c conn_str : database connection string
-i : use INSERT (default = PUT)
-k rows : CHECKPOINT frequency (default = never)
-m rows : COMMIT frequency (default = never)
-n cols : number of non-null columns
-o outfile : record duration in file
-q : quiet mode
-w width : rows to insert per request
-r rows : rows to insert
-v start_value : starting value (for keys)
-x : generate unique row values
We will need further technical details about what your update procedure is doing and how it's executing those updates exactly from the client.
Would you suggest maybe the ODBC Trace Log that I can use on the workstation level?
Tracing ODBC calls via the ODBC Driver Manager can be quite expensive on the client side - this will likely slow down the updates further if you enable it. (Thought: maybe check to see if this has already been enabled recently for other diagnostics...?) It may help to understand both sides of the conversation though if it appears that the database server is processing the updates quickly from a server-side perspective and the client is taking the time to send the updates. I would recommend not running that diagnostic currently until you can narrow down the behaviour a bit more, otherwise you will likely end up collecting a lot more information (at the cost of client performance) than you would otherwise need to.
if I setup a GotoAssist session on this workstation, could someone from SAP log in and watch it and see what is going on or is SAP not allowed to do that?
The rule with remote connections in SAP support is that we can only use the Citrix GotoAssist technology, which is configured for your account/system via KBA 2026090. No alternative screensharing technologies are allowed to be used by SAP technical support (Remote Desktop, TeamViewer, LogMeIn, WebEx, SAP Connect, VNC, etc.). But yes, once the connection is configured for your system, we can make use of the online connection to see what you're seeing and work with you in a live session to help you diagnose the problem further.
Regards,
Jeff Albion
SAP Active Global Support