ldb file and Exclusive Access question

[Andre Laplume via AccessMonster.com]

I have inherited a bunch of dbs which are are shared among a small group in
my dept. We typically use the dbs to write queries to extract data, usually
dumping it into Excel. Most dbs originated in MsAccess 97 or prior and have
been converted to 2003. On occassion user 1 will open a db. When user 2
opens the db it will not let user 2 modify macros and what not. I can
understand this and realize we could split the db; it is not worth the time
though. In this case you always see a .ldb file open with the .mdb file.

Other times after user 1 opens a different db, user 2 will be completely
denied access to it. He/She gets an exclusive access message. In these
cases there appears to be no .ldb file open with the .mdb file. Note that
the database is NOT set to be exclusive(Tools Options Advanced)

The question is, why are these dbs exclusively locked and how can I make them
like the others so folks can at least get in with read access?

--
OOPs a typo...the statement that DOES NOT work is:

AdjAmt: Sum(IIf([TYPE]=2 And Left(Date(),2)="07",[Amt]*[Percent],IIf([TYPE]=1,

[Amt]*[Percent],0)))

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200509/1

[pietlinden]

the blatantly obvious answer is the one you already hinted at... split
the DB and distribute the front end...

[Tom van Stiphout]

On Fri, 16 Sep 2005 17:54:56 GMT, "Andre Laplume via
AccessMonster.com" <fo***@AccessMonster.com> wrote:

Not worth the time??? It would take about as much time as writing
your message.
Why do people continue to cuff their hands between their backs, and
then complain they've lost their dexterity?

-Tom.

I have inherited a bunch of dbs which are are shared among a small group in
my dept. We typically use the dbs to write queries to extract data, usually
dumping it into Excel. Most dbs originated in MsAccess 97 or prior and have
been converted to 2003. On occassion user 1 will open a db. When user 2
opens the db it will not let user 2 modify macros and what not. I can
understand this and realize we could split the db; it is not worth the time
though. In this case you always see a .ldb file open with the .mdb file.

Other times after user 1 opens a different db, user 2 will be completely
denied access to it. He/She gets an exclusive access message. In these
cases there appears to be no .ldb file open with the .mdb file. Note that
the database is NOT set to be exclusive(Tools Options Advanced)

The question is, why are these dbs exclusively locked and how can I make them
like the others so folks can at least get in with read access?

[HERE IS WHY via AccessMonster.com]

Let me be blatant, rest assumed my hands are in front of me. You both may be
right about the splitting. The job I took though did not 'grow up' with
split dbs. We have over 30 of them with Excel sheets linking to them here
and there. Also, I am not the only user of them, there are ohters who have
never split a db in the dept. Management does want the process changed
either as the dbs are cheifly used for simple data extractions, usually by
one person at a time. We will not be given the time to split the dbs nor to
explain/ train the user base on what splitting is nor the time to document
these changes.

I am running into the problem because I am automating the running of some
reports using task scheduler. Task scheduler opens a db and runs a macro.
The macro executes some queries then calls an Access function which opens a
speadsheet, refreshes all the data tabs (this is where the security issue
arises), renames tabs, does some formatting and writes the report to a share
for the end user.

This all works fine for about half our dbs. Some though have the 'exclusive
access' issue I described so when task scheduler opens the db the
spreadsheets will not refresh because the db is already opened exclusively.

No one here is sure why some of the dbs open exclusively and why others allow
numerous folks in with read access to be in the db.

Since splitting is NOT an option, I could likely take a db that allows
subsequent read-only access, empyy it and import all the queries from my
affected db in and rename it. This may eliminate my problem as well...though
it does not answer the original question as to why some open EXCLUSIVELY and
others do not.

Obviously you are not sure either or you would have perhaps explained WHY and
perhaps then issued your snooty remarks.

Sorry if you feel I wasted a post but if you do not know the answer perhaps
its best if you do not repsond at all.

Tom van Stiphout wrote:

Not worth the time??? It would take about as much time as writing
your message.
Why do people continue to cuff their hands between their backs, and
then complain they've lost their dexterity?

-Tom.

I have inherited a bunch of dbs which are are shared among a small group in
my dept. We typically use the dbs to write queries to extract data, usually

[quoted text clipped - 11 lines]

The question is, why are these dbs exclusively locked and how can I make them
like the others so folks can at least get in with read access?

--
Message posted via http://www.accessmonster.com

[Larry Linson]

The good advice you received isn't just a matter of personal preference; if
you have multiple users logged in to the same front end or monolithic
database, the probability of database corruption is significantly increased.

Some people run unsplit for years with no problem, then after they make some
minor, and apparently innocuous change, have frequent occurrences of
database corruption.

Of course, I don't know your management's attitudes regarding schedules
versus data integrity, but I can assure you that in nearly 50 years in the
computer business, I'd have found my job in serious jeopardy if data
integrity was blown and any of my bosses found out that I knew that was
likely to happen, had a good way to prevent it, and didn't. They would, at
least, expect me to explain the situation so they could evaluate the risk of
adhering to a (likely arbitrary) schedule versus making sure the data was
safe.

How often do you get all the users out and make your own backup copy of the
databases? No, the daily backup performed by IT on the servers may NOT be
sufficient, not if there are operations in progress in the Access
applications.

How serious are corruptions? Most of them are a minor inconvenience... get
everybody out of the DB, run Compact and Repair, and you are back in
business. If that happens frequently, during working hours, it can be a
major inconvenience. If Compact and Repair does not fix the problem, it may
be a lot more than an inconvenience.

There are a number of things that can leave "something" running (some call
it a "ghost" process) after the last user seems to have logged out. The best
source of information I know about regarding multiuser performance and
avoiding corruption in the multiuser environment is MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm.

If the users are opening Access, and then running particular databases, I
don't know any way to guard against them logging in for exclusive use. If
they are creating Access objects, they must have exclusive Access in
versions 2000 and later.

Larry Linson
Microsoft Access MVP

[Tim Marshall]

HERE IS WHY via AccessMonster.com wrote:

Since splitting is NOT an option, I could likely take a db that allows
subsequent read-only access, empyy it and import all the queries from my
affected db in and rename it. This may eliminate my problem as well...though
it does not answer the original question as to why some open EXCLUSIVELY and
others do not.

Obviously you are not sure either or you would have perhaps explained WHY and
perhaps then issued your snooty remarks.

HI Andre, let me jump in here.

Tom is not being snooty, but you and the management organization you say
is imposing the approach you descibe in your original post are being
very unwise and you should not expect those of us who try to help to
waste the time to trouble shoot something that you're not using properly.

Here's an analogy:

If you go to a carpentry trades school and you have always used the
hammer claw to drive nails instead of the hammerhead you are going to be
told how to use the hammer properly. It doesn't matter if your company,
your dad and grandfather all used the claw to drive nails, the carpentry
trades school is going to tell you that you are wrong and all the
problems with splitting wood, dents around nail heads etc are less
likely if you use the hammer properly. No teacher there is going to
waste time trying to figure why a 4 by 8 cracks but a smaller 2 by 4
does not when you are using the tool in a way IT WAS NOT DESIGNED TO BE
USED.

If your management organization still stupidly tells you to do it the
way they describe, then it's up to them to trouble shoot the problem.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[HERE IS WHY via AccessMonster.com]

Guys,
I appreciate the 'good advise'...just not the manner in which it was
delivered. If I had my way I'd be using an SQL server to pull the data and
Excel to report it. I'd bundle the whole thing into a nice little
schedulable SQL server package. I did this in my prior job where we ran 100
reports a day from a half dozen different data sources inclusing several we
made ourselves.

My current position is not as sophisticated nor is it really necesary to be
so. We essentially have a warehouse (source data) on an SQL server.
Typically an Access data base will link to that server, pull in some data and
report it via Access (Me I prefer to link Excel to the resultant table in
Access)

There really is little chance of data corruption as we do not UPDATE the sql
server warehouse from Access. It is possible that some YTD tables we keep
could beocome corrputed. They could easily be recreated by running a query
for the year instead of just appending the current month. Also, typically
there is ONLY 1 of 4 possible people in the db at a time. Yes, I have a
little task scheduler package that zips the dbs each night in addition to the
IT backup.

Again, we do not have an access APPLICATION running in my area with multiple
users logged in. Other areas do have such enterprises and they do split the
db. I am not arguing that it is a good practice. I would be nice to have
the time to consolidate our dbs, rename them, rewrite some queries for better
efficiency and even likely consolidate and eliminate some reports. Still we
are limited on heads and limited on budget and I can see why management would
not want us to invest out time doing this fo4 simple data extractions. Newly
created dbs sure but existing ones are not worth the effort at this point. I
am as proactive as I am able. This is why instead of hitting a button to run
a report that is generated every day, I chose to try to develop a quick
little method to schedule it. This is where I hit my little security snafu.

This problem arises when I access a function to open an Excel file, refresh
the pivots and save the file under a different name. It worked fine in the
first db fro the 1st report I wanted to schedule. I tried the same thing for
a different process in a second db and was getting General ODBC errors on the
functions: refresh ALL command and the task scheduler task died. I was
perpelexed until I realized that both myself and cohort could not be in the
db at the same time. It was then we started opening dbs and found that
sometimes we could each be in and sometimes not..

SHARED ACCESS in my experience always has meant who ever has the db opened
first can modify stuff. Subsequent users are allowed in but granted read-
only access.

EXCLUSIVE ACCESS in my experience always meant who ever opens the db first
owns it; no one else gets in.

The question I was asking was what made some of our dbs open EXLCUSIVELY and
others open SHARED when each was apprently defaulted to SHARED mode and why
do not see a .lbd file when opened exclusively.

So forgive me for perhaps overreacting but does anyone know the answers......
PS:
I have eperienced a problem in the past where the .lbd file stays out there
and the .mdb is gone; thus you delete the .ldb and you are fine. This has
nothing to do my issue.

PSS:
The 3 of us all have the same security.

Larry Linson wrote:

The good advice you received isn't just a matter of personal preference; if
you have multiple users logged in to the same front end or monolithic
database, the probability of database corruption is significantly increased.

Some people run unsplit for years with no problem, then after they make some
minor, and apparently innocuous change, have frequent occurrences of
database corruption.

Of course, I don't know your management's attitudes regarding schedules
versus data integrity, but I can assure you that in nearly 50 years in the
computer business, I'd have found my job in serious jeopardy if data
integrity was blown and any of my bosses found out that I knew that was
likely to happen, had a good way to prevent it, and didn't. They would, at
least, expect me to explain the situation so they could evaluate the risk of
adhering to a (likely arbitrary) schedule versus making sure the data was
safe.

How often do you get all the users out and make your own backup copy of the
databases? No, the daily backup performed by IT on the servers may NOT be
sufficient, not if there are operations in progress in the Access
applications.

How serious are corruptions? Most of them are a minor inconvenience... get
everybody out of the DB, run Compact and Repair, and you are back in
business. If that happens frequently, during working hours, it can be a
major inconvenience. If Compact and Repair does not fix the problem, it may
be a lot more than an inconvenience.

There are a number of things that can leave "something" running (some call
it a "ghost" process) after the last user seems to have logged out. The best
source of information I know about regarding multiuser performance and
avoiding corruption in the multiuser environment is MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm.

If the users are opening Access, and then running particular databases, I
don't know any way to guard against them logging in for exclusive use. If
they are creating Access objects, they must have exclusive Access in
versions 2000 and later.

Larry Linson
Microsoft Access MVP

--
Message posted via http://www.accessmonster.com

[Mike Preston]

On Mon, 19 Sep 2005 19:38:06 GMT, "HERE IS WHY via AccessMonster.com"
<fo***@AccessMonster.com> wrote:

This problem arises when I access a function to open an Excel file, refresh
the pivots and save the file under a different name. It worked fine in the
first db fro the 1st report I wanted to schedule. I tried the same thing for
a different process in a second db and was getting General ODBC errors on the
functions: refresh ALL command and the task scheduler task died. I was
perpelexed until I realized that both myself and cohort could not be in the
db at the same time. It was then we started opening dbs and found that
sometimes we could each be in and sometimes not..

SHARED ACCESS in my experience always has meant who ever has the db opened
first can modify stuff. Subsequent users are allowed in but granted read-
only access.

EXCLUSIVE ACCESS in my experience always meant who ever opens the db first
owns it; no one else gets in.

The question I was asking was what made some of our dbs open EXLCUSIVELY and
others open SHARED when each was apprently defaulted to SHARED mode and why
do not see a .lbd file when opened exclusively.

So forgive me for perhaps overreacting but does anyone know the answers......
PS:
I have eperienced a problem in the past where the .lbd file stays out there
and the .mdb is gone; thus you delete the .ldb and you are fine. This has
nothing to do my issue.

PSS:
The 3 of us all have the same security.

It sounds like Larry gave you the reason.

Maybe.

I am perplexed by your statement that the .mdb is locked when there is
no .ldb. Sounds strange, although I don't have time to check how it
works at this time.

In any event, if you run a process that attempts to modify an Access
object, the database will be locked at that point. So do you have a
macro or something else which runs on the db that doesn't allow
mutliple users to access it at one time?

mike

[David W. Fenton]

"HERE IS WHY via AccessMonster.com" <fo***@AccessMonster.com> wrote
in news:54***********@AccessMonster.com:

Let me be blatant, rest assumed my hands are in front of me. You
both may be right about the splitting. The job I took though did
not 'grow up' with split dbs. We have over 30 of them with Excel
sheets linking to them here and there. . . .
Well, that sounds bad to me. In order for multiple users to edit an
Excel spreadsheet simultaneously, they have to open it in a
particular mode (I forget the details -- I don't recommend it to
clients because it's just way to easy to corrupt the whole
spreadsheet). So far as I know, there's no way to link to an Excel
spreadsheet from Access that allows multi-user access to the
spreadsheet.

So, as long as the data is in Excel spreadsheets, there's no
solution -- it's not even an issue of splitting the front end, as
you're already split, since the data tables are not in the MDB in
the first place.
. . . Also, I am not the only
user of them, there are ohters who have never split a db in the
dept. . . .
Well, if you had an unsplit Access database, and you split it, the
end users WOULD NEVER KNOW. The way you do it is keep the old MDB as
the front end, move the data tables into a different MDB and link to
them from the old MDB. As far as everyone else is concerned, the
tables are still there in the same MDB file.

Of course, it's not a good idea to share an MDB, either, but that's
yet another issue.
. . . Management does want the process changed either as the dbs
are cheifly used for simple data extractions, usually by one
person at a time. We will not be given the time to split the dbs
nor to explain/ train the user base on what splitting is nor the
time to document these changes.
Tom's original response seems correct to me, then -- he tells you
your hands are tied behind your backs, and your refuse to untie the
rope.

There is no possibility of helping you when you refuse the only
solutions that could possibly fix the problem.
I am running into the problem because I am automating the running
of some reports using task scheduler. Task scheduler opens a db
and runs a macro. The macro executes some queries then calls an
Access function which opens a speadsheet, refreshes all the data
tabs (this is where the security issue arises), renames tabs, does
some formatting and writes the report to a share for the end user.
I would suggest importing the Excel data into an MDB file (not the
one people use for writing their queries, etc., but another one),
then you will no longer have problems with other user conflicts
preventing you from accessing the data.
This all works fine for about half our dbs. Some though have the
'exclusive access' issue I described so when task scheduler opens
the db the spreadsheets will not refresh because the db is already
opened exclusively.
If it's Excel data, you can't get around the issue, except if you
can guarantee that nobody else has the spreadsheet open (either in
Excel or via the link in your Access MDB).
No one here is sure why some of the dbs open exclusively and why
others allow numerous folks in with read access to be in the db.
Have you made sure that everyone's copy of Access defaults to
opening MDBs in shared mode?

Even if they don't, giving each individual their own MDB would
actually solve *that* problem, as then the front end MDB would not
be opened by one person at a time.
Since splitting is NOT an option, I could likely take a db that
allows subsequent read-only access, empyy it and import all the
queries from my affected db in and rename it. This may eliminate
my problem as well...though it does not answer the original
question as to why some open EXCLUSIVELY and others do not.
Sorry, but you can't be helped at all if you absolutely refuse THE
ONLY METHOD FOR SOLVING YOUR PROBLEM.
Obviously you are not sure either or you would have perhaps
explained WHY and perhaps then issued your snooty remarks.
Well, from where I sit, you look like a pointy-haired-Dilbert-boss
type, who requires that you build a bridge across the river without
using any steel.
Sorry if you feel I wasted a post but if you do not know the
answer perhaps its best if you do not repsond at all.

You've already been given the correct answer.

You've rejected it, so you're not going to solve your problem, ever.

That's not Tom's fault.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"HERE IS WHY via AccessMonster.com" <fo***@AccessMonster.com> wrote
in news:54***********@AccessMonster.com:

SHARED ACCESS in my experience always has meant who ever has the
db opened first can modify stuff. Subsequent users are allowed in
but granted read- only access.
No, that's wrong. If it's all Jet data, then everyone gets the write
access they are allowed by Jet security (which is, by default, full
control).
EXCLUSIVE ACCESS in my experience always meant who ever opens the
db first owns it; no one else gets in.

From your explanation, it sounds like your problem is with Excel
data, and not with Access. Lose Excel as a data store, and you'll
probably no longer have an issue.

It occurs to me, though, given your mention of pivot tables, that
you may be using Excel to analyze data stored in an MDB. In that
case, I don't know what the issues are, as I"ve never used Excel
that way. I've never needed anything other than Access crosstab
queries, which so far as I can see, offer most of the functionality
of pivot tables (though it's not nearly as easy to do).

Basically, if you moved more of the functionality and data storage
into Access, instead of trying to interface with Excel (in either
direction), I think you'd have fewer problems, as Access is designed
from the ground up to be multi-user, whereas Excel only supports it
as a bolted-on feature that doesn't work too well.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Albert D. Kallal]

Do be aware that access97 did allow users to modify forms and reports while
other users were in the database.

In a2000, and later (that means for the last 3 versions of ms-access), you
CAN NOT modify a form, or reports while other users are in the database.

So, in effect, if you modify a form, you now have the database in exclusive
mode.

The result of the above change normally is not a big deal, since most of use
split the database.

However, this change does "hit" some folks like you, who don't have much
multi-user stuff, and don't want to split the database.

So, perhaps you are modifying some forms, or reports?

It is also simply a possibility that some users are using the file->open
dialog in ms-access, and the "exclusive" box it checked when they open the
database.

Another possible is that the default for some users is set to exclusive.
(So, change default mode to shared: you can find this under
tools->options->advanced tab - "default mode = shared")

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[HERE IS WHY via AccessMonster.com]

I really appreciate all the responses and advise...some good other not so.
I love the ones that say what I am doing can not be done. I laugh because it
IS being done right now. It WAS being done at my old job as our chief means
of reporting..we ran over 100 reports each night where Access pulled the data
and Excel pointed to it providing the end user data tabs and pivots. Perhaps
though I have not been clear; though I am really unsure what it has to do
with my original question; nevertheless here is how we report here:

1) Open an existing Access db that contains the group of SQL server tables we
wish to link. Our dbs is grouped by function (think Po database, Ap database,
Payroll database etc)

2) Write one or more queries to extract desired data from SQL server tables.
The end result of the queries will be an ACCESS table containing the source
data for the report.

3a) Create an ACCESS Report (we stay away from this where possible except for
simple lists as these reports are not very manipulative).

3b) Open Excel. On a worksheet pull the data into a data tab or pivot from
the ACCESS Table created in step 2. Save the Excel file with the word
TEMPLATE in it (just to distiguish it as a template file and not the final
report) . In the future when the Access data has been refreshed, open the
template, refresh the data and save it under a new name to a share.

THIS ALL WORKS.

I simply wanted to automate the action of Opening Excel, refreshing the data
and saving the file to the share. I added a simple function in MsAccess taht
does so, then added an ACCESS macro (to be scheduled by the task scheduler)
that runs the queries and executes the function.

THIS WORKS IN SEVERAL DATABASES AND FURTHER OUR REPORTING FUNCTIONALITY WAS
BUILT AROUND THIS PREMISE AT MY PRIOR JOB!

What created my initial question was the fact that it did NOT work in ONE
particular db. It was then I discovered that that db (a a couple other I
have found since) open 'exclusively' where as other dbs open 'shared'.

So we can philosophically argue reporting techniques until we are blue in the
face, I likely will not change your thoughts and so long as I can write a
few quieries, create an Excel template, schedule the process to to refresh
the template over night and never look back...well this is the route I am
going. I do not wish to sit here manually running 50 reports a day when they
can be run over night.
The real question simply was/is: Why is it sometimes one particular db opens
EXCLUSIVELY and another opens SHARED! I think I have you all stumped.....

PS: the one good thought I heard was whether everyone had there Access set
to opn in shared mode, yes we all do!

THANKS!

Albert D. Kallal wrote:

Do be aware that access97 did allow users to modify forms and reports while
other users were in the database.

In a2000, and later (that means for the last 3 versions of ms-access), you
CAN NOT modify a form, or reports while other users are in the database.

So, in effect, if you modify a form, you now have the database in exclusive
mode.

The result of the above change normally is not a big deal, since most of use
split the database.

However, this change does "hit" some folks like you, who don't have much
multi-user stuff, and don't want to split the database.

So, perhaps you are modifying some forms, or reports?

It is also simply a possibility that some users are using the file->open
dialog in ms-access, and the "exclusive" box it checked when they open the
database.

Another possible is that the default for some users is set to exclusive.
(So, change default mode to shared: you can find this under
tools->options->advanced tab - "default mode = shared")

--
Message posted via http://www.accessmonster.com

[Tim Marshall]

HERE IS WHY via AccessMonster.com wrote:

I really appreciate all the responses and advise...some good other not so.
I love the ones that say what I am doing can not be done. I laugh because it
IS being done right now. It WAS being done at my old job as our chief means
of reporting..

Driving nails with the claw of a hammer...

People try to help, he won't listen.

<PLONK>
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Gord]

Question: Do all of your users have write permissions on the _folder_
in which the shared Access databases reside? If not, then that can
explain why no .ldb file is created if the .mdb is opened first by a
user with read-only access to the folder. In that case *all other
users* will have difficulty accessing the database until the first user
closes it.

[HERE IS WHY via AccessMonster.com]

Yup, one of the things I WAS allowed to do is consolidate all the dbs to one
folder. We are all set up the same. Like I said, I open db1. My buddy
opens db1 and gets in but with 'read' access. You can see a .ldb file out
there. Close everything. I open db2. My buddy opens db2 but can not get in.
...gives her the exclusive access speil. Also, in this case I see no .ldb
file. Its weird but some dbs let multiple users in and some will not. I
have to believe there is a simple answer....splitting might solve the problem
buut does not answer the question.
Gord wrote:

Question: Do all of your users have write permissions on the _folder_
in which the shared Access databases reside? If not, then that can
explain why no .ldb file is created if the .mdb is opened first by a
user with read-only access to the folder. In that case *all other
users* will have difficulty accessing the database until the first user
closes it.

--
Message posted via http://www.accessmonster.com

[SOLUTION--maybe via AccessMonster.com]

I am not claiming this makes any sense but....

I went to exporer and drill may way to the folder that houses our dbs. I
went to properties. Under: Attributes, ReadOnly was greyed out with a check
mark. I clicked it. The box lit up with nothing in it. I clicked: APPLY.
I clocked OK when asked if it should be applied to all files/subfolder there
in.

Now when more than one person opens those previously 'always' exclusive dbs,
they open shared and I see the .ldb file.

Like I said I am unsure if this makes sense or not but part of my problem
appears to be resolved.

Thanks!

HERE IS WHY wrote:

Yup, one of the things I WAS allowed to do is consolidate all the dbs to one
folder. We are all set up the same. Like I said, I open db1. My buddy
opens db1 and gets in but with 'read' access. You can see a .ldb file out
there. Close everything. I open db2. My buddy opens db2 but can not get in.
..gives her the exclusive access speil. Also, in this case I see no .ldb
file. Its weird but some dbs let multiple users in and some will not. I
have to believe there is a simple answer....splitting might solve the problem
buut does not answer the question.

Question: Do all of your users have write permissions on the _folder_
in which the shared Access databases reside? If not, then that can
explain why no .ldb file is created if the .mdb is opened first by a
user with read-only access to the folder. In that case *all other
users* will have difficulty accessing the database until the first user
closes it.

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"HERE IS WHY via AccessMonster.com" <fo***@AccessMonster.com> wrote
in news:54***********@AccessMonster.com:

I
have to believe there is a simple answer....splitting might solve
the problem buut does not answer the question.

You are a cmplete idiot.

<PLONK>

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[SOLUTION--maybe via AccessMonster.com]

Yes, since I do not know all the minutia of Access I am a complate idiot.
Forgive me for posting a simple question (which still really has not been
answered).

All I know is I used to have to generate numerous reports via an Access form,
tedious job of running queries and manipulating the data to Excel. Now it
will all be set up and run over night freeing me to do other things.

Yea, I am an idiot.

I'll make sure I steer clear of the 'general' area from now.

David W. Fenton wrote:

I
have to believe there is a simple answer....splitting might solve
the problem buut does not answer the question.

You are a cmplete idiot.

<PLONK>

--
Message posted via http://www.accessmonster.com

[David W. Fenton]

"SOLUTION--maybe via AccessMonster.com" <fo***@AccessMonster.com>
wrote in news:54***********@AccessMonster.com:

David W. Fenton wrote:

I
have to believe there is a simple answer....splitting might
solve the problem buut does not answer the question.

You are a cmplete idiot.

<PLONK>

Yes, since I do not know all the minutia of Access I am a complate
idiot. Forgive me for posting a simple question (which still
really has not been answered).

All I know is I used to have to generate numerous reports via an
Access form, tedious job of running queries and manipulating the
data to Excel. Now it will all be set up and run over night
freeing me to do other things.

Yea, I am an idiot.

I'll make sure I steer clear of the 'general' area from now.

If you'd posted the explanation originally that you posted
yesterday, explaining what you were actually doing, you would have
gotten much better answers.

The reason you got the answers you did was because your original
posts basically misrepresented your situation, so people gave you
advice that wasn't relevant.

But that's not *their* fault. It may not even be your fault, since
sometimes it's difficult to know what we don't know. But your
belligerence in response to the answers you got turned off a number
of people (me being among them).

If you'd explained yourself earlier, instead of attacking the people
who attempted to answer your ill-defined question, then perhaps
you'd be in fewer killfiles today.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc