Hello ! Recently we built a stored procedure that can help to determine, from a SQL Server session, the Mega user that owns it. I attached it here in a text file. Once it is installed, the syntax to call it is, for example : EXEC SP_FIND_MEGA_END_USER_NAME 'Standard_SQL', 'db', '51' The three parameters are : - The Mega environment name - The name of the Mega working database (as it is shown in the Administration tool) - The ID of the session in SQL Server Thus, if the customer wants to have something more, he will indeed have to write more SQL scripts to retrieve all sessions linked to some databases for example, and then call the stored procedure described above for all session IDs. Feel free to ask for more information if needed. Regards, Olivier Schiavi
... View more
Hello ! I think the main issue here is the network side. Can you tell us what kind of bandwidth you have between the server where you launched the diagnostic, and the database server, exists ? And what is maybe even more important, could you check the latency between those two ? I'm afraid it's the weakest point here. To test the latency, you can follow the below procedure : On a client computer running MEGA, it is recommended to ping the RDBMS server with a filled buffer to have an evaluation of the infrastructure. In order to do this, Mega redistributes free of charges a tool called hrPING, located in the <Mega installation Path>\Utilities\RDBMS Diagnostic directory. Use it with the following command in a command window from a computer that will be running Mega (web server and user desktop): hrping.exe -W -l 5000 -n 50 -y <RDBMS Server name or IP> It gives a min/max/average result of the latency, in milliseconds. If you can show us the result, it would confirm (or not) this theory.
... View more