Is file is being used

  • Thread starter Thread starter Eran.Yasso
  • Start date Start date
E

Eran.Yasso

Hi,

I have a mdb file shared in the LAN. I want to write app that verifies
if it's open.
If the file is not open, then my app can open the file.
if the file is used, then the app won't open it.

I also want this app to have handle to this file, then when the user
stops editting this file, he can close it using this app.

so my questions are:

1. How can i tell if a file is being used(edited, open, etc'...)
2. How can i close file(and save the data)?

TIA.
 
1. How can i tell if a file is being used(edited, open, etc'...)
Click to expand...

Try to open it with exclusive access. If you succeed, it's not being used.
2. How can i close file(and save the data)?
Click to expand...

Data is "saved" as you write to the file, though not necessarily the exact
moment you do so. You can use the Close method on the various file i/o
classes to ensure that the file is actually closed and the buffers have been
completely flushed.

Pete
 
Hi,

I have a mdb file shared in the LAN. I want to write app that verifies
if it's open.
If the file is not open, then my app can open the file.
if the file is used, then the app won't open it.

I also want this app to have handle to this file, then when the user
stops editting this file, he can close it using this app.

so my questions are:

1. How can i tell if a file is being used(edited, open, etc'...)
2. How can i close file(and save the data)?

TIA.
Click to expand...

If I'm not wrong a MDB generates a temporary lock file when it is open,
with the same name but the extension .LDB. You can try checking for the
existence of that file to know if its is open

As for closing it from another application -- not sure about that
 
Rad said:
If I'm not wrong a MDB generates a temporary lock file when it is open,
with the same name but the extension .LDB. You can try checking for the
existence of that file to know if its is open

As for closing it from another application -- not sure about that
Click to expand...

Oh man, thanks.
Now I know what's that ldb mean. Lock data base.
thanks, i wounder if i ldb file holds any information on the user who's
using the file and if i can parse the file.

does the ldb file is being deleted when the mdb file is stopped being
used?
does the ldb file is being created as soon as someone else opens the
file?

Maybe i should get response to this in WinAPI news group?
 
Peter said:
Try to open it with exclusive access. If you succeed, it's not being used.


Data is "saved" as you write to the file, though not necessarily the exact
moment you do so. You can use the Close method on the various file i/o
classes to ensure that the file is actually closed and the buffers have been
completely flushed.

Pete
Click to expand...

Hi Pete thanks for the response,
How can i use the exclusive access?
is it a class?

thanks,
 
Oh man, thanks.
Now I know what's that ldb mean. Lock data base.
thanks, i wounder if i ldb file holds any information on the user who's
using the file and if i can parse the file.

does the ldb file is being deleted when the mdb file is stopped being
used?
does the ldb file is being created as soon as someone else opens the
file?

Maybe i should get response to this in WinAPI news group?
Click to expand...

Yep. It creates the lock as soon as the database is opened and deletes it
as soon as the database is closed.

Try it and see. Open the mdb in access and then navigate to the folder in
Windows Explorer
 
Hi Pete thanks for the response,
How can i use the exclusive access?
is it a class?
Click to expand...

No...it's simply a part of the parameters you pass when you open the file.
I believe that the default is to open read/write with exclusive access, so
you may not have to specify anything at all. You should check the
documentation to be sure though.
 
Rad said:
Yep. It creates the lock as soon as the database is opened and deletes it
as soon as the database is closed.
Click to expand...

Note that using the presence or content of the .ldb file isn't the right
answer for the original question.

Between the time one looks to see if the .ldb file exists, the status of the
database file could change. Knowing whether the .ldb file exists at time A
tells you nothing about whether you can successfully open the .mdb file at
time B.

If you want to know whether you can successfully open a file exclusively,
the only correct solution is to attempt to open the file exclusively. Any
other method can only provide hints as to whether the operation will succeed
or not, and in particular one will *always* still have to handle the case
where the operation fails even though there's no .ldb file at the time one
checks.

This is a classic issue for a wide variety of computer resources that one
desires to gain exclusive rights to. Whether a file, mutex, i/o port,
whatever...the only reliable means of determining whether one can get access
is to try getting access. Any other method wastes time checking something
that may or may not be valid later when one actually tries to get access.

Pete
 
Note that using the presence or content of the .ldb file isn't the right
answer for the original question.
Click to expand...

I beg to differ.

He asked quite explicitly *How can i tell if a file is being used(edited,
open, etc'...)* What you're saying about exclusive use may be true, but is
not what OP asked.

The presence of the lock file is a perfectly valid answer to the question
of whether the file has been opened or not.
 
Rad said:
I beg to differ.

He asked quite explicitly *How can i tell if a file is being used(edited,
open, etc'...)* What you're saying about exclusive use may be true, but is
not what OP asked.

The presence of the lock file is a perfectly valid answer to the question
of whether the file has been opened or not.
Click to expand...

Beg to differ all you want. His intent is clear to me. In addition to what
you quoted, he also wrote:

"If the file is not open, then my app can open the file."

and

"I also want this app to have handle to this file"

His application cannot open the file unless it's not already open by someone
else, and the only way to know whether he will be successful in opening the
file is to try doing it. Checking for the presence of a .ldb file tells him
nothing. If the file is absent, the .mdb file could still be unopenable,
and if the file is there, it's still possible that his application could
open the .mdb. The presence of the .ldb doesn't tell him anything about
whether he can actually open the .mdb file or not.

His post is clearly intended to not only find out whether the file has been
opened, but whether HIS application can open it. In any case, even if he
wants to know only whether the .mdb file is open, again...the only way to do
that is to look at that file. There is no way to atomically open one file
and create another simultaneously, and so there is no way a second file can
provide 100% accurate information about the state of another file.

Of course, neither of us will know for sure what his intent is unless he
posts and clarifies. But it's my opinion that his initial post is clear
enough, and he clearly wants access to the .mdb file. Even if he doesn't,
he can't reliably know the state of the .mdb file by looking at something
other than the .mdb file.

Pete
 
What I find to be amazing is that this thread exists in 2006.

A system on which I was programming in 1976 that only had 16K of RAM and
supported up to 16 attached (via coax) workstations supported the
concept of "Open Private". Stated simply, if a file was already open,
even if the other workstation had done an "Open Shared", my open would
fail. The unit that functioned as the "cluster controller" took care of
this for me. File and record locks were forced, not cooperative.

By the way, the system was a Singer/ICL 1500 series manufactured in
Utica, NY. It saw a lot of use in the retail market as it also was
capable of supporting electronic cash registers (POS devices).

Mike
..
 
Mike Klaene said:
What I find to be amazing is that this thread exists in 2006.
Click to expand...

Me too, but not for the reason you apparently find it to be.
A system on which I was programming in 1976 that only had 16K of RAM and
supported up to 16 attached (via coax) workstations supported the concept
of "Open Private". Stated simply, if a file was already open, even if the
other workstation had done an "Open Shared", my open would fail. The unit
that functioned as the "cluster controller" took care of this for me. File
and record locks were forced, not cooperative.
Click to expand...

They are as well under Windows (and other operating systems for that
matter...I can't think of a single multi-process operating system that
*doesn't* have this feature).

That some people may want to write code that attempts to add yet another
layer on top of the file system doesn't change the fact that the file system
itself provides this functionality inherently. It only illustrates the
foolishness of trying to layer a cooperative file locking mechanism on top
of the built-in operating system mechanism.

Pete
 
Peter said:
Me too, but not for the reason you apparently find it to be.


They are as well under Windows (and other operating systems for that
matter...I can't think of a single multi-process operating system that
*doesn't* have this feature).

That some people may want to write code that attempts to add yet another
layer on top of the file system doesn't change the fact that the file system
itself provides this functionality inherently. It only illustrates the
foolishness of trying to layer a cooperative file locking mechanism on top
of the built-in operating system mechanism.

Pete
Click to expand...

Peter, nice to see pepole with the ammount of experience like you who
reading posts of noobs like me.

On to the subject...
Why wouldn't access let more then one user access the file in the same
time? mdb file is not an ordinary file. think of it as multi file. it
has tables. one can edit table while other edit other table. it
shouldn't affect each other. Unless they edit the same table.
Sorry for my English.

BTW, I was listening to Bob Dylan - Like A Rolling Stone :)
 
Peter, nice to see pepole with the ammount of experience like you who
reading posts of noobs like me.
Click to expand...

We were all "noobs" at one time. For that matter, even the most experienced
of us are *still* "noobs" in any variety of topics.
On to the subject...
Why wouldn't access let more then one user access the file in the same
time?
Click to expand...

You'd have to ask the Access folks to get the exact details. But the
general issue is that you can't safely have more than one arbitrary process
writing to a file at the same time. There's no way to resolve how to
coordinate the processes, and so the resulting file is non-deterministic.

For example, imagine two processes writing the strings "ABCDE" and "abcde"
respectively, one byte at a time, to a file they both have open for writing
at the same time. The file could wind up looking like any of the following:

* "ABCDEabcde"
* "AaBbCcDdEe"
* "ABaCDbEcde"
* "ABCabcdDEe"

or any other possible interleaving of the two strings. There's no way to
allow both processes simultaneous access to the file and still have a
well-defined consequence to them both writing to the file simultaneously.

The easiest, most straight-forward solution is to ensure that only one
process can write to the file at a time. Once a process has closed a file,
there's nothing it can do to ensure that no other process will change the
file. But at least it knows while it has the file open, it can write to the
file and leave the file in a well-defined state.
mdb file is not an ordinary file. think of it as multi file. it
has tables. one can edit table while other edit other table. it
shouldn't affect each other. Unless they edit the same table.
Click to expand...

The file system doesn't know anything about the content of the .mdb file.
It has no way to ensure that one process only makes changes to the file that
affect one table, while another process only makes changes to the same file
that affect a different table.

That said, most database do support multiple users, and they do so by
providing an actual database server through which the database can be
accessed. This adds a robust layer on top of the file itself that *does*
define how different processes can modify the file at the same time, and
which *does* understand the higher-level structure of the file (independent
tables, for example).

Note that even in the case of a database server supporting multiple
processes, it still enforces one-at-a-time access to any single part of the
database, and there are still possible conflicts between different
processes. Having the database server doesn't make the problems go
away...it just abstracts them into a more usable scenario, where the manner
in which processes cooperate is better-defined.

Pete
 
Peter said:
We were all "noobs" at one time. For that matter, even the most experienced
of us are *still* "noobs" in any variety of topics.


You'd have to ask the Access folks to get the exact details. But the
general issue is that you can't safely have more than one arbitrary process
writing to a file at the same time. There's no way to resolve how to
coordinate the processes, and so the resulting file is non-deterministic.

For example, imagine two processes writing the strings "ABCDE" and "abcde"
respectively, one byte at a time, to a file they both have open for writing
at the same time. The file could wind up looking like any of the following:

* "ABCDEabcde"
* "AaBbCcDdEe"
* "ABaCDbEcde"
* "ABCabcdDEe"

or any other possible interleaving of the two strings. There's no way to
allow both processes simultaneous access to the file and still have a
well-defined consequence to them both writing to the file simultaneously.

The easiest, most straight-forward solution is to ensure that only one
process can write to the file at a time. Once a process has closed a file,
there's nothing it can do to ensure that no other process will change the
file. But at least it knows while it has the file open, it can write to the
file and leave the file in a well-defined state.


The file system doesn't know anything about the content of the .mdb file.
It has no way to ensure that one process only makes changes to the file that
affect one table, while another process only makes changes to the same file
that affect a different table.

That said, most database do support multiple users, and they do so by
providing an actual database server through which the database can be
accessed. This adds a robust layer on top of the file itself that *does*
define how different processes can modify the file at the same time, and
which *does* understand the higher-level structure of the file (independent
tables, for example).

Note that even in the case of a database server supporting multiple
processes, it still enforces one-at-a-time access to any single part of the
database, and there are still possible conflicts between different
processes. Having the database server doesn't make the problems go
away...it just abstracts them into a more usable scenario, where the manner
in which processes cooperate is better-defined.

Pete
Click to expand...

Pete, you are right if mdb file was an ordinary file. But, MDB file has
tables. You can look at this tables as many different files attached to
a big file. if both proccess don't write to the same table, then they
are not "sharing the same memory"(file).
 
Pete, you are right if mdb file was an ordinary file. But, MDB file has
tables. You can look at this tables as many different files attached to
a big file. if both proccess don't write to the same table, then they
are not "sharing the same memory"(file).
Click to expand...


No, an mdb file is just a "regular" file and only "Access" knows about the internal
structure, the OS does know anything about tables etc...
Access is a desktop "personal productivity tool", meant to be used from a single
user/process, it's not designed to be accessed from multiple users/processes simultaneously.
A single "access" process locks the file, and prevents other processes to access the file,
simply because it can not deal with shared accesses to it's mdb files.
If you want multiple clients to access the same DB you have to use client server based DB
products like MSSQL or Oracle. And even then, MSSQL won't allow another "process" to access
it's underlying database files, only the Server can access these *files*, and all accesses
from external clients must go through the server.

Willy.
 
Pete, you are right if mdb file was an ordinary file. But, MDB file has
tables. You can look at this tables as many different files attached to
a big file. if both proccess don't write to the same table, then they
are not "sharing the same memory"(file).
Click to expand...

See Willy's reply. As far as the file system is concerned, a .mdb IS just
"an ordinary file".

Every file is a "special file", as viewed by applications that understand
them. But the file system treats all files as basically the same. Even a
..mdb file is simply a single stream of bytes, to Windows. The tables are
completely unknown to Windows and Windows has no way of inherently dealing
with multiple simultaneous write access to .mdb files (or any other type of
file).

Pete
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Word After a re-boot all Word files were changed to Picture files 4
Will not auto open .jpg 1
Outlook Stops Downloading emails 5
Excell 2021 0
Create and sort on XML File 4
News Fitness apps can be used to track down names and addresses of users 2
Excel Unlink open excel files 2
problem with file handles 2

Back
Top