By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,400 Members | 981 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,400 IT Pros & Developers. It's quick & easy.

Help! Table locking issue in report with no sub report etc.

P: n/a
RWC
Hello,

I have an issue that's driving me batty! I have a report, whose record
source is SQL based on a normalized set of tables. There are no nested
queries and no dlookups in this record source. When I run this record
source on it's own, it functions normally with no errors.

The report that this SQL is designed over, contains no subreports, no
dlookups, and has no code associated with it, yet when I try to run it, I
get an error "The database engine could not lock the table 'genCompanies'
because it is already in use by another person or process". This database
is a stand alone, on my laptop. I only have the single application open,
and do not have any other objects open. There is no code running in the
back ground that would open anything related to this table (because there's
no code operating in the back ground). Any help with this issue would be
greatly appreciated, because it seems to defy logic at this point.

Thanks in advance!
RWC

P.S. If you are replying to this post, please remove the caps and
underscores from my email address..Thanks!
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"RWC" <he*************************@shaw.ca> wrote in message
news:7vovc.651419$Ig.204871@pd7tw2no...
Hello,

I have an issue that's driving me batty! I have a report, whose record
source is SQL based on a normalized set of tables. There are no nested
queries and no dlookups in this record source. When I run this record
source on it's own, it functions normally with no errors.

The report that this SQL is designed over, contains no subreports, no
dlookups, and has no code associated with it, yet when I try to run it, I
get an error "The database engine could not lock the table 'genCompanies'
because it is already in use by another person or process". This database
is a stand alone, on my laptop. I only have the single application open,
and do not have any other objects open. There is no code running in the
back ground that would open anything related to this table (because there's no code operating in the back ground). Any help with this issue would be
greatly appreciated, because it seems to defy logic at this point.

Thanks in advance!
RWC

P.S. If you are replying to this post, please remove the caps and
underscores from my email address..Thanks!


RWC,
Wild guess #1: on the form, do you have any list or combo boxes which are
populated via queries into the genCompanies table? If so and if the queries
are not marked 'Read Only' or similar, you might be hitting the contention
right there: the form's recordset cannot lock the table because the control
has an updateable recordset open already.
Just my $0.02
Doug

--
Remove the blots from my address to reply
Nov 13 '05 #2

P: n/a
RWC
Hey Doug, thanks for the response. I did wind up correcting it, but it
seems like odd behaviour none the less. The problem was on a report, no
combo boxes, no dlookups, nothing, that's what was driving me nuts. For
some reason, the report property "Record Locks" was set to "All Records"
instead of "No Records". I'm not sure why this became a problem all of a
sudden, or why it would prevent the report from running altogether.

Anyway, resolved...thanks for the help though. ;)

RWC.

"Doug Hutcheson" <do*****************@nrm.blot.qld.blot.gov.blot.au > wrote
in message news:hy**************@news.optus.net.au...
"RWC" <he*************************@shaw.ca> wrote in message
news:7vovc.651419$Ig.204871@pd7tw2no...
Hello,

I have an issue that's driving me batty! I have a report, whose record
source is SQL based on a normalized set of tables. There are no nested
queries and no dlookups in this record source. When I run this record
source on it's own, it functions normally with no errors.

The report that this SQL is designed over, contains no subreports, no
dlookups, and has no code associated with it, yet when I try to run it, I get an error "The database engine could not lock the table 'genCompanies' because it is already in use by another person or process". This database is a stand alone, on my laptop. I only have the single application open, and do not have any other objects open. There is no code running in the
back ground that would open anything related to this table (because there's
no code operating in the back ground). Any help with this issue would be greatly appreciated, because it seems to defy logic at this point.

Thanks in advance!
RWC

P.S. If you are replying to this post, please remove the caps and
underscores from my email address..Thanks!


RWC,
Wild guess #1: on the form, do you have any list or combo boxes which are
populated via queries into the genCompanies table? If so and if the

queries are not marked 'Read Only' or similar, you might be hitting the contention
right there: the form's recordset cannot lock the table because the control has an updateable recordset open already.
Just my $0.02
Doug

--
Remove the blots from my address to reply

Nov 13 '05 #3

P: n/a
"RWC" <he*************************@shaw.ca> wrote:
I did wind up correcting it, but it
seems like odd behaviour none the less. The problem was on a report, no
combo boxes, no dlookups, nothing, that's what was driving me nuts. For
some reason, the report property "Record Locks" was set to "All Records"
instead of "No Records". I'm not sure why this became a problem all of a
sudden, or why it would prevent the report from running altogether.


That's very wierd. Thanks for posting.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.