Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 21 to 28 of 28 total |
Problem with Multiple Users in Shared File Mode |
Fri, Mar 9 2007 9:02 AM | Permanent Link |
Gordon Turner | Roy Lambert wrote:
> > Since it seems to be the logon/startup of the app which causes the problem why not try a special version which writes out log messages to a file. You can make it as fine as you like, even after each line of code. That at least should allow you to pinpoint where the problem is. > > My only other suggestion is to get them to change the machine used as the fileserver (use one of the workstations for experimentation) in case its the network setting and not releasing a lock. > They are running such a special version now, but because the application hangs and they have to end-task it, how much do you trust the information in the log to be complete? Were entries generated by the logging function actually written to disk, or lost in the buffer when the task was killed? CodeSite uses a special dispatcher to receive and log messages (very useful when trying to debug painting or drawing problems) so I think the log is complete, but I can't be sure. At this point in time, it appears the program hangs as it is opening tables. (I log a message just before the Open statement.) To open the tables, the app cycles through the Datamodule components, opening any object that is a DBISAMTable... if (Components[i] is TDBISAMTable) then begin try with TDBISAMTable(Components[i]) do begin sStopWords := TextIndexStopWords; Exclusive:=False; ReadOnly:=False; Open; if ReadOnly = True then begin {Display message about read only access} Application.Terminate; Exit; end; end; except on E: EDBISAMEngineError do begin {exception handling messages end; end; end; -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Fri, Mar 9 2007 10:04 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Gordon
In that case - how far away from you are they? Roy Lambert |
Fri, Mar 9 2007 10:11 AM | Permanent Link |
Sean McCall | Gordon,
Have you made sure that all anti-virus software is turned off? I have seen long delays in opening tables due to AV issues but never full hangs... but one never knows. What happens if you open two application instances on the same machine? If it hangs in that case maybe you can reproduce it at your site. Good luck, Sean Gordon Turner wrote: > Roy Lambert wrote: >> >> Since it seems to be the logon/startup of the app which causes the >> problem why not try a special version which writes out log messages to >> a file. You can make it as fine as you like, even after each line of >> code. That at least should allow you to pinpoint where the problem is. >> >> My only other suggestion is to get them to change the machine used as >> the fileserver (use one of the workstations for experimentation) in >> case its the network setting and not releasing a lock. >> > > They are running such a special version now, but because the application > hangs and they have to end-task it, how much do you trust the > information in the log to be complete? Were entries generated by the > logging function actually written to disk, or lost in the buffer when > the task was killed? CodeSite uses a special dispatcher to receive and > log messages (very useful when trying to debug painting or drawing > problems) so I think the log is complete, but I can't be sure. > > At this point in time, it appears the program hangs as it is opening > tables. (I log a message just before the Open statement.) To open the > tables, the app cycles through the Datamodule components, opening any > object that is a DBISAMTable... > > if (Components[i] is TDBISAMTable) then begin > try > with TDBISAMTable(Components[i]) do begin > sStopWords := TextIndexStopWords; > Exclusive:=False; > ReadOnly:=False; > Open; > if ReadOnly = True then begin > {Display message about read only access} > Application.Terminate; > Exit; > end; > end; > except > on E: EDBISAMEngineError do begin > {exception handling messages > end; > end; > end; > |
Fri, Mar 9 2007 11:54 AM | Permanent Link |
Gordon Turner | Progress Report...
(Thanks all for your suggestions and ideas.) The customer let the second workstation run for a while and it eventually connected to all of the tables (it took several minutes), so the application will connect, it just seems to take a long time. Unfortunately, I wasn't smart enough to include time stamps or tick counts in the debugging messages last time, so I'm not sure exactly where the delays occurred, but I'm going to do that now. (I prepare several queries after the data files are opened.) (I'll also mention the AV option to see if that has an impact, but since the first connection happens normally, I'm not sure if this is a factor.) Tim... Are there retry loops in the DBISAM table component code that may be executing a number of times before actually connecting? Is there some aspect of network setup or traffic that we should look at for time delays? Everyone... Is there any other debugging information I should try to gather for the next pass? -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Fri, Mar 9 2007 12:21 PM | Permanent Link |
Sean McCall | Gordon,
I would also make sure OpLocks are disabled in the OS. The problem could also be caused by a delay in the request for the first workstation to release the exclusive lock on the file & drop it down to shared so that the second workstation can begin to use the file. Sean Gordon Turner wrote: > Progress Report... > > (Thanks all for your suggestions and ideas.) > > The customer let the second workstation run for a while and it > eventually connected to all of the tables (it took several minutes), so > the application will connect, it just seems to take a long time. > > Unfortunately, I wasn't smart enough to include time stamps or tick > counts in the debugging messages last time, so I'm not sure exactly > where the delays occurred, but I'm going to do that now. (I prepare > several queries after the data files are opened.) > > (I'll also mention the AV option to see if that has an impact, but since > the first connection happens normally, I'm not sure if this is a factor.) > > Tim... > > Are there retry loops in the DBISAM table component code that may be > executing a number of times before actually connecting? Is there some > aspect of network setup or traffic that we should look at for time delays? > > Everyone... > > Is there any other debugging information I should try to gather for the > next pass? > |
Fri, Mar 9 2007 1:14 PM | Permanent Link |
"Jose Eduardo Helminsky" | Gordon
Change the server registry at following key and check if it helps. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters autodisconnect REG_DWORD 0xffffff enableforcedlogoff REG_DWORD 0x1 enablesecuritysignature REG_DWORD 0 EnableOplocks REG_DWORD 0 CachedOpenLimit REG_DWORD 0 Eduardo |
Fri, Mar 9 2007 6:58 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Sean,
<< I would also make sure OpLocks are disabled in the OS. The problem could also be caused by a delay in the request for the first workstation to release the exclusive lock on the file & drop it down to shared so that the second workstation can begin to use the file. >> Yes, it is possible that this may be the case. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Mar 9 2007 7:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< The customer let the second workstation run for a while and it eventually connected to all of the tables (it took several minutes), so the application will connect, it just seems to take a long time. >> See my response to Sean. He may be on to something here - it may be that the OpLocks are taking too long to get rid of the exclusive open and make the files available for shared use. It certainly would explain the environmental aspect of things and why it works fine for most clients but not this one. Given that the application isn't changing at all, it has to be something environmental. << Are there retry loops in the DBISAM table component code that may be executing a number of times before actually connecting? >> Only in terms of waiting for a read lock to read the table headers. However, unless the first workstation is taking several minutes to create the tables, then this won't have any bearing on the situation because that's the only way that a read lock would be blocked out for that long. If the first workstation pops right up, but the second workstation keeps waiting and waiting, then I would look into the above issue with the OpLocks. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 3 of 3 | |
Jump to Page: 1 2 3 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |