Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
Exclusive Table Access in V4.25 |
Thu, Feb 22 2007 12:21 PM | Permanent Link |
Gordon Turner | In moving my app from shared file DBISAM to CS DBISAM I'm stumbling
across a methodology problem. In shared file mode, I check for exclusive access to the table before I allow the user to delete base records by: with BaseTable do try Close; Exclusive := True; Open; except on E: EDBISAMEngineError do begin {display message to try again later} end; end; (The tables are normally opened in Shared mode - Exclusive := false) When I try to run the same code in CS mode, I get the 11013 error, even if I am the only user accessing the table. Is the reason why I can't open the file exclusively simply because I am accessing it through the server? If so, is there another way to test whether or not I am the only user accessing the server data files? -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Fri, Feb 23 2007 7:51 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< When I try to run the same code in CS mode, I get the 11013 error, even if I am the only user accessing the table. Is the reason why I can't open the file exclusively simply because I am accessing it through the server? If so, is there another way to test whether or not I am the only user accessing the server data files? >> C/S behaves in exactly the same way as local in terms of exclusive/shared access to tables. Are you sure that you didn't change something else in your code ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, May 1 2007 2:03 AM | Permanent Link |
"Norman Rorke" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:739E6CEC-D7BE-4A81-85B0-1EFE44AB5842@news.elevatesoft.com... > Gordon, > > << When I try to run the same code in CS mode, I get the 11013 error, even > if I am the only user accessing the table. Is the reason why I can't open > the file exclusively simply because I am accessing it through the server? > If so, is there another way to test whether or not I am the only user > accessing the server data files? >> > I have been experiencing the same problem. The problem was reported to me by a client who's nightly backup (tape) occasionally fails with "cannot access file" error. Once the error occurs it can only be resolved by resetting the DBISAM server. The problem started since they moved to C/S. Norman Rorke Desktop Financials Ltd |
Tue, May 1 2007 6:39 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< I have been experiencing the same problem. The problem was reported to me by a client who's nightly backup (tape) occasionally fails with "cannot access file" error. Once the error occurs it can only be resolved by resetting the DBISAM server. The problem started since they moved to C/S. >> Are they specifically getting an #11013 error from DBISAM, or a general OS error from the backup application ? Also, remember that anti-virus software has been causing these sorts of problems with DBISAM's temporary tables for some time now. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, May 2 2007 4:11 AM | Permanent Link |
"Norman Rorke" | Tim,
It's an OS message. Apparently the table continues to be accessible for read/write via DBISAM while the error is in place . But the clients backup app will continues to report "unable to access" every night until DBISAMCS is stopped & restarted. The strange thing is that this affects only one specific table out of 66 within the database. Norman "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:90EDCE70-6F71-4A36-BC4F-9C65FEC395BA@news.elevatesoft.com... > Norman, > > << I have been experiencing the same problem. The problem was reported to me > by a client who's nightly backup (tape) occasionally fails with "cannot > access file" error. Once the error occurs it can only be resolved by > resetting the > DBISAM server. The problem started since they moved to C/S. >> > > Are they specifically getting an #11013 error from DBISAM, or a general OS > error from the backup application ? Also, remember that anti-virus software > has been causing these sorts of problems with DBISAM's temporary tables for > some time now. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Wed, May 2 2007 3:50 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< It's an OS message. Apparently the table continues to be accessible for read/write via DBISAM while the error is in place . But the clients backup app will continues to report "unable to access" every night until DBISAMCS is stopped & restarted. The strange thing is that this affects only one specific table out of 66 within the database. >> Is it a table file or the lock file (dbisam.lck) ? If it's a table file, then you need to make sure that there are no sessions present on the database server before trying the backup, or switch to using the built-in DBISAM backup functionality. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, May 8 2007 6:49 PM | Permanent Link |
"Norman Rorke" | Tim,
I have checked that there are no sessions open. Regarding using the DBISAM backup. I have suggested that, but this is a corporate client and they refuse to change their infrastructure to accommodate my "little" application. It does not make sense to them that their DBISAM data cannot be backed up at 3am when there is nobody working. I will continue to investigate and, if I cannot locate the problem, might switch them back to local DSBISAM which they have been on for some years until recently. Norman "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:0283509B-ECCB-4F5B-BF13-79561FC763F8@news.elevatesoft.com... > Norman, > > << It's an OS message. Apparently the table continues to be accessible for > read/write via DBISAM while the error is in place . But the clients backup > app will continues to report "unable to access" every night until DBISAMCS > is stopped & restarted. The strange thing is that this affects only one > specific table out of 66 within the database. >> > > Is it a table file or the lock file (dbisam.lck) ? If it's a table file, > then you need to make sure that there are no sessions present on the > database server before trying the backup, or switch to using the built-in > DBISAM backup functionality. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Tue, May 8 2007 7:37 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Norman,
<< I have checked that there are no sessions open. >> If there are no sessions open, then there is no way for the database server to have any tables open. You can use the FileMon utility from (now MS) sysinternals to monitor what files are open: http://www.microsoft.com/technet/sysinternals/FileAndDisk/Filemon.mspx or you can use their Process Monitor utility also: http://www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx That way you can see for yourself that no files are actually open. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |