Can multiple Oinsight loads be prevented. (OpenInsight 32-Bit)
At 01 OCT 2003 09:57:11AM John Bouley wrote:
I have a customer that is having problems with OI 4.13. Sometimes a user will log into OI twice. Is there a way of preventing this from happening?
Thanks,
John
At 01 OCT 2003 08:02PM Donald Bakke wrote:
John,
Sometimes a user will log into OI twice. Is there a way of preventing this from happening?
Does this thread give you any ideas?
At 02 OCT 2003 09:36AM John Bouley wrote:
Thanks Donald,
Yes it gives me ideas but doesn't give me the solution…
If I understand correctly, we have to write a VB executable that launches OInsight if and only if it can not find Oinsight loaded into memory. Any sample code??
Thanks,
John
At 02 OCT 2003 03:55PM Donald Bakke wrote:
John,
That's one way of doing it. I don't have any code examples but we did write a similar "launch" utility in C++. We plan to package this eventually as a generic application launcher. One of the reasons we wrote this is so splash screens can be displayed for a preset length of time while the actual OI application can load in the background.
A less sophisticated (and less expensive) approach would be to handle this from with OI. You can create a token record in a table or update an INI file on the workstation and check this upon launching the application. If this token is still around then assume they are already running OI and have it close itself automatically. The only problem with this approach is that OI can close prematurely for various reasons (including workstation crashes) and these tokens are left in place and have to be removed manually.
A third, middle-of-the-road, approach is to use OI to detect if other instances of OI are already running. If you have familiarity with the Windows API (i.e. FindWindow) then this can be done fairly easily as well.
At 02 OCT 2003 04:37PM Pat McNerthney wrote:
The only problem with this approach is that OI can close prematurely for various reasons (including workstation crashes) and these tokens are left in place and have to be removed manually.
A record lock should be cleared in such situations.
Pat
At 02 OCT 2003 05:10PM Donald Bakke wrote:
Pat,
A record lock should be cleared in such situations.
Do you mean *should* as in "the system should do it automatically" or as in "we should unlock it ourselves"? I assume the former.
Unfortunately we have seen situations where locks are not released and we either have to reboot the server or turn off/on the Service.
One situation that *always* causes us problems is when I'm running an OI application mapped to the server but before I log off I disconnect my machine (i.e. my laptop) and go home. The server still thinks I'm connected. My SYSLOGINS record is still locked. This lock stays in place until I do one of the above steps. Even reconnecting with my laptop doesn't resolve the problem.
At 02 OCT 2003 09:45PM Pat McNerthney wrote:
Don,
Do you mean *should* as in "the system should do it automatically" or as in "we should unlock it ourselves"? I assume the former.
Correct, the former.
Unfortunately we have seen situations where locks are not released and we either have to reboot the server or turn off/on the Service.
Hmm…using named pipes, tcp/ip, or either?
One situation that *always* causes us problems is when I'm running an OI application mapped to the server but before I log off I disconnect my machine (i.e. my laptop) and go home. The server still thinks I'm connected. My SYSLOGINS record is still locked. This lock stays in place until I do one of the above steps. Even reconnecting with my laptop doesn't resolve the problem.
I have heard of this reported in the field from other sites, but try as I might, I have been unable to reproduce this problem in house. I would love to get this one figured out if you have a consistently reproducable scenario.
I just tried once again to create this problem. I have tried everything I can think of, from unplugging the network cable from the client, terminating the application as if a gpf happened, etc. Everytime, the server finally times out and clears the connection.
Here is a MicroSoft technical bulletin about this very issue in relationship to SQL Server: INF: How to Troubleshoot Orphaned Connections in SQL Server
Take a peek at that and see if it provides any clues about what might be causing this at your site.
Thanks,
Pat
At 02 OCT 2003 10:51PM Donald Bakke wrote:
Pat,
I have asked Paul from our office to review the article and reply to your questions.
FWIW, I'm one of the prime culprits of causing this problem in our office. I have a laptop which is connected to a port replicator. Therefore, when I leave the office I either put my machine to sleep and disconnect from the replicator or just disconnect. Perhaps one of these is the "magic bullet".
At 03 OCT 2003 11:01AM Paul Simonsen wrote:
We are running the 2.1 service in both Named Pipes and TCP/IP mode on an NT4 server.
I just did some more tests in our office and here is what I came up with. The key is putting your computer to sleep/hibernation. Once that is done, then remove the computer from the network and close OpenInsight. I have been able to consistently cause the SYSLOGINS lock to remain in these situations. The only way to clear the lock is by restarting the Linear Hash service.
Let me know if you want me to do any additional tests.