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

Temp database wouldn't open from jump drive

P: n/a
When my app starts up, it creates a temporary database. This temp database
is created from a 'model' database that is in the same folder as the
application. Because there is a model, the creation is essentially to just
copy the 'model' database and give it the name of the application with the
extension ".tmp".

Then code opens the temp database and links to the tables. This has always
worked flawlessly until today. Today, I needed to open my app on a client
computer. So I copied all the necessary files to a folder on a "jump" drive.
I then ran everything from the jump drive on the client's computer.
Everything worked fine, but the links to the tables in the temp DB were not
valid. The links could be seen in the database window, but clicking on them
gave an error. When I went to the code that did this creation, it could be
seen that the temp DB was created (this was verified by going to Windows
Explorer to check the existence of the temp DB that was just created).
Here's the relevant code:

Set dbsTemp = wrkDefault.OpenDatabase(strTempDatabase)
dbsTemp.TableDefs.Refresh

If dbsTemp.TableDefs.Count < 1 Then
dbsTemp.Close
Set dbsTemp = Nothing
Exit Sub
End If

At the line "If dbsTemp.TableDefs.Count < 1, the error "Object not set" was
encountered.

I found this very puzzling as all needed files were on the jump drive and in
the correct folder, and most importantly, I could see that the tempDB
(strTempDatabase) had been created.

Now, without changing code, I took the same jump drive and plugged it into my
laptop and opened the app from the jump drive. Everything worked just fine
including linking to the tables in the temporary database.

So, I'm stumped and I'm looking for some possible ideas as to what happened.

Additional information: My laptop has Windows XP Home and the client machine
is Windows 2000 Professional. The client machines have been "locked" down to
some degree (i.e. executables cannot be run and downloading from the internet
is very difficult). Is it possible that when I tried to connect to the temp
DB on the jump drive that this was viewed as not allowed? I find that hard
to understand, because my app was located on the jump drive and it was opened
within Access which was on the client's machines.

Finally, although I didn't have time to check this out: I've never had
problems running my app (including creating the temp DB and linking to the
tables in it) on my client's machine in the past. However, in the past all
files have always been on the client machine's hard drive.

Any ideas, thoughts, suggestions, appreciated.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 26 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
folder permissions ?
read-only files on jump drive ?
if you rename the jump drive db from xxx.tmp to xxx.mdb, can you open
it with access ?

robert d via AccessMonster.com wrote:
When my app starts up, it creates a temporary database. This temp database
is created from a 'model' database that is in the same folder as the
application. Because there is a model, the creation is essentially to just
copy the 'model' database and give it the name of the application with the
extension ".tmp".

Then code opens the temp database and links to the tables. This has always
worked flawlessly until today. Today, I needed to open my app on a client
computer. So I copied all the necessary files to a folder on a "jump" drive.
I then ran everything from the jump drive on the client's computer.
Everything worked fine, but the links to the tables in the temp DB were not
valid. The links could be seen in the database window, but clicking on them
gave an error. When I went to the code that did this creation, it could be
seen that the temp DB was created (this was verified by going to Windows
Explorer to check the existence of the temp DB that was just created).
Here's the relevant code:

Set dbsTemp = wrkDefault.OpenDatabase(strTempDatabase)
dbsTemp.TableDefs.Refresh

If dbsTemp.TableDefs.Count < 1 Then
dbsTemp.Close
Set dbsTemp = Nothing
Exit Sub
End If

At the line "If dbsTemp.TableDefs.Count < 1, the error "Object not set" was
encountered.

I found this very puzzling as all needed files were on the jump drive and in
the correct folder, and most importantly, I could see that the tempDB
(strTempDatabase) had been created.

Now, without changing code, I took the same jump drive and plugged it into my
laptop and opened the app from the jump drive. Everything worked just fine
including linking to the tables in the temporary database.

So, I'm stumped and I'm looking for some possible ideas as to what happened.

Additional information: My laptop has Windows XP Home and the client machine
is Windows 2000 Professional. The client machines have been "locked" down to
some degree (i.e. executables cannot be run and downloading from the internet
is very difficult). Is it possible that when I tried to connect to the temp
DB on the jump drive that this was viewed as not allowed? I find that hard
to understand, because my app was located on the jump drive and it was opened
within Access which was on the client's machines.

Finally, although I didn't have time to check this out: I've never had
problems running my app (including creating the temp DB and linking to the
tables in it) on my client's machine in the past. However, in the past all
files have always been on the client machine's hard drive.

Any ideas, thoughts, suggestions, appreciated.

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


Jan 26 '06 #2

P: n/a
Thanks, for the response.

See my comments below. I'm going to try a few more things today, including
copying the files from the jump drive to the cient machine's hard drive to
see if that works (it always has in the past).

I'll report back.

le*********@natpro.com wrote:
folder permissions ? Folder permissions on the jump drive? If that were the case, why can I run
the app (with creation of temp DB and linking to temp dB tables) from the
jump drive when it is connected to my laptop?read-only files on jump drive ? I don't think it can be this because I can run the app perfectly fine
(including temp DB creation and linking to tables) from the jump drive when
using my laptop.if you rename the jump drive db from xxx.tmp to xxx.mdb, can you open
it with access ?
When my app starts up, it creates a temporary database. This temp database
is created from a 'model' database that is in the same folder as the

[quoted text clipped - 49 lines]

Any ideas, thoughts, suggestions, appreciated.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 26 '06 #3

P: n/a
It turns out that I have the same problem when I copy the files to the hard
drive of th client's computer. It looks like the error is that I don't have
permissions to use the temp object.

I am using workgroup security and RWOP queries on both my main backend and on
the tables in the temp DB. I have followed MS Access FAQ on Security where
it says you need to have On Error Resume Next when trying to link to RWOP
queries with user permissions revoked on the tables. This still works fine
on my main backend, but no longer on the temp dB on the client's machine.
But I can link to the temp DB tables on my laptop with no problem using the
same code.

In both cases I'm logged on as a member of the Admins group??

I have no idea what is going on??

robert d wrote:
Thanks, for the response.

See my comments below. I'm going to try a few more things today, including
copying the files from the jump drive to the cient machine's hard drive to
see if that works (it always has in the past).

I'll report back.
folder permissions ?

Folder permissions on the jump drive? If that were the case, why can I run
the app (with creation of temp DB and linking to temp dB tables) from the
jump drive when it is connected to my laptop?
read-only files on jump drive ?

I don't think it can be this because I can run the app perfectly fine
(including temp DB creation and linking to tables) from the jump drive when
using my laptop.
if you rename the jump drive db from xxx.tmp to xxx.mdb, can you open
it with access ?

[quoted text clipped - 4 lines]

Any ideas, thoughts, suggestions, appreciated.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 26 '06 #4

P: n/a
Okay.

I've located what is causing the problem. The workgroup files seem to be out-
of-sync. When trying to run this on the client's machine, I was using the
old workgroup file. when I copied over the workgroup file from my laptop it
works fine. I also realized that this is the first time that I've tried to
run a version of my app on the client's machine where a temporary DB is
created.

I'll have to ferret the rest of this out on my own.

Thanks.

robert d wrote:
It turns out that I have the same problem when I copy the files to the hard
drive of th client's computer. It looks like the error is that I don't have
permissions to use the temp object.

I am using workgroup security and RWOP queries on both my main backend and on
the tables in the temp DB. I have followed MS Access FAQ on Security where
it says you need to have On Error Resume Next when trying to link to RWOP
queries with user permissions revoked on the tables. This still works fine
on my main backend, but no longer on the temp dB on the client's machine.
But I can link to the temp DB tables on my laptop with no problem using the
same code.

In both cases I'm logged on as a member of the Admins group??

I have no idea what is going on??
Thanks, for the response.

[quoted text clipped - 17 lines]

Any ideas, thoughts, suggestions, appreciated.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200601/1
Jan 26 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.