Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Exclusive Table Access in V4.25
Thu, Feb 22 2007 12:21 PMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image