• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1028
  • Last Modified:

Unlocking Tables not used by anyone while other users are using the DB

I have a DB used by 20 users at any given time.  There is an administrative routine that drop and creates tables.  Users have no access to these tables.

When users are in the DB though I get the following message:

"You tried to lock table '900 Available Hours Prep 1a' while opening it, but the table cannot be locked because it is currently in use. Wait a moment, and then try the operation again"


I tried with the following code but I get the same message:

             DoCmd.DeleteObject acTable, "900 Available Hours Prep 1a"
0
fitaliano
Asked:
fitaliano
  • 5
  • 3
  • 2
  • +1
1 Solution
 
GRayLCommented:
It's time you learned - I don't talk to people who put spaces in names, bye.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Yes, PLEASE adopt proper nameing conventions. This will end up biting you at some point.

Access can lock several tables for a single operation, depending on the relationships between those tables. It's entirely possible that your drop/recreate routines are impacting this, and locking those tables.

Is there a reason you must drop the table? In most cases it's better to delete the information and then just refill the table. This would almost certainly stop your error message as well.

And please - do something about your object names. There's just no reason to name a table like that, and if you EVER have to move up to SQL Server you'll find that those names aren't allowed.
0
 
fitalianoAuthor Commented:
I changed the name to 900_Available_Hours_Prep_1a"

Any suggestion to solve my issue now?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I'll restate my question to you:

Is there a reason you must drop the table? In most cases it's better to delete the information and then just refill the table. This would almost certainly stop your error message as well.

0
 
Vadim RappCommented:
You can try to delete .ldb file in the same directory as the mdb.

In case the file is locked on the system level, you can try utilities described at this webpage: http://www.howtohaven.com/system/deleteundeletablefiles.shtml. But it's all quite unstable, and may result in data loss and in damage to the data in the database, so it would be better to come up with less intrusive solution.

By the way, there's absolutely nothing wrong in having spaces in table names, except the little trouble of enclosing these names in quotes whenever they are used. They are also supported in SQL Server (source: http://msdn.microsoft.com/en-us/library/ms175874.aspx )
0
 
fitalianoAuthor Commented:
the reason why i drop the table is because I have complex calculations that I'm staging putting data in some tables and doing other queries on these staging tables up to some other tables and so on...

0
 
GRayLCommented:
vadimrapp1:  Google - Access naming convention - the first three hits say do not use spaces - one even says do not use underscores - I'm a believer.
0
 
Vadim RappCommented:
GrayL, author's thread is not the best place for discussions between experts; if you want, we can open a private thread to discuss your beliefs.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
<By the way, there's absolutely nothing wrong in having spaces in table names, except the little trouble of enclosing these names in quotes whenever they are used. They are also supported in SQL Server (source: http://msdn.microsoft.com/en-us/library/ms175874.aspx ) >

The document you cite specifically states this in the "Rules for Regular Identifiers" section:

"4. Embedded spaces or special characters are not allowed."

And further:

"Identifiers that do not comply with all the rules for identifiers must be delimited in a Transact-SQL statement. For example: "

So you CAN use them - they're just not allowed, as I stated in my earlier comment. You must take special care to delimit them correctly in order to use them in your code, just as you do when working with non-standard object names in Access.

0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
<the reason why i drop the table is because I have complex calculations that I'm staging putting data in some tables and doing other queries on these staging tables up to some other tables and so on...>

Understood, however if you're simply using SELECT INTO for your make table stuff, you can easily convert that to INSERT INTO and avoid the possibility of locking tables while dropping them. Granted you could still have lock issues when doing the INSERTS, but those would be more rare with a single user (i.e. you) doing the INSERTS.

If you could explain a bit more about your process perhaps we could assist further.
0
 
Vadim RappCommented:
Now that the main question is resolved - regarding the spaces in table names: what the document says is the identifiers can be regular and delimited. There's nothing that says that delimited are somehow inferior to the regular, or that either of them are recommended over another, not to mention "aren't allowed".

Also, if I may, I think it's more productive and courteous to the question author to first resolve the problem he posted, and only by that to earn in his eyes the authority to give general advise criticizing his coding style - even when that advise is 100% right on target.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
"4. Embedded spaces or special characters are not allowed."

I don't see how that is ambiguous or vague in any way. I realize that the article does go further to say  that if you decide to use characters or conventions which are disallowed, then you must take special steps to insure they can be parsed correctly.

Also, I'd be willing to bet that if you asked this question to the experienced developer community at large, you'd find a very solid (if not overwhelming) majority of those developers would come down on the side of "no spaces in object names", regardless of what environment we're talking about (i.e. db development, app developement, etc). This may change at some point, of course, but I don't see it changing in the near future.

And, as _alias99 said in your Community Support request, this might be more appropriate to continue in the Experts Lounge or the Access Discussion thread.

0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now