Unable to access folder from A2003

[rdemyan via AccessMonster.com]

With A2003, I'm having trouble accessing files in a folder on another
computer where back-end files, update files, etc are located. Here's the
scenario:

1) Computer #1 - A2003
2) Computer #2 - Access 2000; folder with back-ends for both computers and
'Update' folder.

I have a launcher program that launces my application (MyApp). The launcher
program also checks for updates to MyApp located in 'Update' folder (on
Computer #2). If there is an update file in the 'Update' folder, the
launcher program opens it with a DAO recordset and gets the version number.
If the version number of MyApp in the 'Update' folder is higher than the
version number of MyApp on Computer #1, then MyApp in the 'Update' folder is
downloaded and replaces MyApp on Computer #1.

All of this code works fine. The problem is that on Computer #1 (A2003),
I've been having problems accessing MyApp in the 'Update' folder. I keep
getting a message that 'MyApp' in the 'Update' folder is already opened
exclusively. I am 100% sure that it is not open and there is no .ldb file.

HOWEVER, if I create a new folder ('NewFolder') on Computer #2, where the
Update folder is located, then copy MyApp in the 'Update' folder to
'NewFolder', and then reset the location on the launching program on Computer
#1 to 'NewFolder' (where the launching program searches for updates),
everything works fine. No more exclusivity errors.

I've seen this before. It's like files in the folder on Computer #2 somehow
can now longer be accessed by A2003 (I never have this problem with A2K).

Now I can solve the problem simply by creating a new folder on Computer #2
using Windows Explorer and copying the files into it. Then I can delete the
old folder and rename the new folder with the old folder name. But clients
aren't going to want to do this.

What is causing this problem??? I'm not doing anything with Windows folders
permissions. Both computers run Windows XP home editions.

Thank you for any ideas, suggestions,etc.

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

[Wayne Morgan]

What is the command line that your launcher program uses to open Access and
the database once it is assured that you have the current front-end? Is
Access on all computers set to open in Shared mode as a default
(Tools|Options|Advanced tab)? Are there any restrictions on the shared
folder limiting the number of users? Do the front-end, back-end, or
workgroup (mdw) file have the same first part of their name (i.e.
MyDatabase.mdw, MyDatabase.mdb)?

--
Wayne Morgan
MS Access MVP
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:60a244275175c@uwe...

With A2003, I'm having trouble accessing files in a folder on another
computer where back-end files, update files, etc are located. Here's the
scenario:

1) Computer #1 - A2003
2) Computer #2 - Access 2000; folder with back-ends for both computers and
'Update' folder.

I have a launcher program that launces my application (MyApp). The
launcher
program also checks for updates to MyApp located in 'Update' folder (on
Computer #2). If there is an update file in the 'Update' folder, the
launcher program opens it with a DAO recordset and gets the version
number.
If the version number of MyApp in the 'Update' folder is higher than the
version number of MyApp on Computer #1, then MyApp in the 'Update' folder
is
downloaded and replaces MyApp on Computer #1.

All of this code works fine. The problem is that on Computer #1 (A2003),
I've been having problems accessing MyApp in the 'Update' folder. I keep
getting a message that 'MyApp' in the 'Update' folder is already opened
exclusively. I am 100% sure that it is not open and there is no .ldb
file.

HOWEVER, if I create a new folder ('NewFolder') on Computer #2, where the
Update folder is located, then copy MyApp in the 'Update' folder to
'NewFolder', and then reset the location on the launching program on
Computer
#1 to 'NewFolder' (where the launching program searches for updates),
everything works fine. No more exclusivity errors.

I've seen this before. It's like files in the folder on Computer #2
somehow
can now longer be accessed by A2003 (I never have this problem with A2K).

Now I can solve the problem simply by creating a new folder on Computer #2
using Windows Explorer and copying the files into it. Then I can delete
the
old folder and rename the new folder with the old folder name. But
clients
aren't going to want to do this.

What is causing this problem??? I'm not doing anything with Windows
folders
permissions. Both computers run Windows XP home editions.

Thank you for any ideas, suggestions,etc.

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

[rdemyan via AccessMonster.com]

Thanks for the response:

1) Not sure why the command line to launch MyApp (located in a folder on the
local computer) is an issue. The launcher has not had problems launching the
MyApp program. It's the opening of MyApp update file on the peer computer
that is the issue. Keep getting exclusivity problems.

HOWEVER: I looked at the command-line arguments shown in the
(Tools|Options|Advanced tab) between A2000 and A2003. THEY ARE DIFFERENT.
When I launch MyApp, I pass in some information including the location of the
back-end files, the workgroup file and some boolean variables that tell MyApp
what to connect to and where the workgroup file is (I need the workgroup file
because MyApp also can launch other workgroup protected files. A2003,however,
only shows the workgroup file in the Command-line argument!!??

One other difference is the DDE operations. A2003 has 'Enable DDE Refresh'
while A2K has nothing checked.

BUT, the problem I'm having is within the launching program not MyApp once it
opens.

2) Yes Access on all computers is set to open in Shared mode.

3) To be honest, I don't even know how to set restrictions on shared folders
in Windows XP Home Edition. Windows Explorer on any of the peer computers
can see the 'Update' folder (and files within) located on Computer #2.
There's only one user right now, so I'm not sure that would be the issue.

4) All files have different names.

All I did to eventually get this to work was create a new folder on Computer
#2 (which is acting as the server) and copy the files located in the 'Update'
folder (which is giving me the problems) to the NewFolder. Then I change the
folder location on the launcher on Computer #1 to NewFolder from Update and
everything works fine!!??

Could this be an A2003 problem. A2000 has never exhibited this problem.

Wayne Morgan wrote:

What is the command line that your launcher program uses to open Access and
the database once it is assured that you have the current front-end? Is
Access on all computers set to open in Shared mode as a default
(Tools|Options|Advanced tab)? Are there any restrictions on the shared
folder limiting the number of users? Do the front-end, back-end, or
workgroup (mdw) file have the same first part of their name (i.e.
MyDatabase.mdw, MyDatabase.mdb)?

With A2003, I'm having trouble accessing files in a folder on another
computer where back-end files, update files, etc are located. Here's the

[quoted text clipped - 44 lines]

Thank you for any ideas, suggestions,etc.

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

[Wayne Morgan]

Ok, just to clarify, are you having problems copying the updated file or
opening your app once you've made sure that you have the most current file?

The command line will make a difference, especially if it has the /excl
switch on it. This opens the file exclusively. Where you looks in the
Options isn't what I was referring to. I was referring to the command line
used to open your app. It would be something like:

"<path>\msaccess.exe" "<path>\MyDatabase.mdb" /wrkrgp
"<path>\MyWorkgroup.mdw" /user UserName /pwd Password

What happens if you open the app without using the updater first, do the
problems go away? I suspect that the updater is locking the file for some
reason.

--
Wayne Morgan
MS Access MVP
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:60a30d52ce523@uwe...

Thanks for the response:

1) Not sure why the command line to launch MyApp (located in a folder on
the
local computer) is an issue. The launcher has not had problems launching
the
MyApp program. It's the opening of MyApp update file on the peer computer
that is the issue. Keep getting exclusivity problems.

HOWEVER: I looked at the command-line arguments shown in the
(Tools|Options|Advanced tab) between A2000 and A2003. THEY ARE DIFFERENT.
When I launch MyApp, I pass in some information including the location of
the
back-end files, the workgroup file and some boolean variables that tell
MyApp
what to connect to and where the workgroup file is (I need the workgroup
file
because MyApp also can launch other workgroup protected files.
A2003,however,
only shows the workgroup file in the Command-line argument!!??

One other difference is the DDE operations. A2003 has 'Enable DDE
Refresh'
while A2K has nothing checked.

BUT, the problem I'm having is within the launching program not MyApp once
it
opens.

2) Yes Access on all computers is set to open in Shared mode.

3) To be honest, I don't even know how to set restrictions on shared
folders
in Windows XP Home Edition. Windows Explorer on any of the peer computers
can see the 'Update' folder (and files within) located on Computer #2.
There's only one user right now, so I'm not sure that would be the issue.

4) All files have different names.

All I did to eventually get this to work was create a new folder on
Computer
#2 (which is acting as the server) and copy the files located in the
'Update'
folder (which is giving me the problems) to the NewFolder. Then I change
the
folder location on the launcher on Computer #1 to NewFolder from Update
and
everything works fine!!??

Could this be an A2003 problem. A2000 has never exhibited this problem.

Wayne Morgan wrote:

What is the command line that your launcher program uses to open Access
and
the database once it is assured that you have the current front-end? Is
Access on all computers set to open in Shared mode as a default
(Tools|Options|Advanced tab)? Are there any restrictions on the shared
folder limiting the number of users? Do the front-end, back-end, or
workgroup (mdw) file have the same first part of their name (i.e.
MyDatabase.mdw, MyDatabase.mdb)?

With A2003, I'm having trouble accessing files in a folder on another
computer where back-end files, update files, etc are located. Here's
the

[quoted text clipped - 44 lines]

Thank you for any ideas, suggestions,etc.

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

[rdemyan via AccessMonster.com]

I was having trouble copying the update file. There are no /excl switches
on my command lines.

Opening the app is not the issue as it opens fine. It is copying down the
updated app to overwrite the existing app that is the problem. The error
causes a failure in the copying. Thereafter, the existing (non-updated app)
opens just fine.

Thanks.

Wayne Morgan wrote:

Ok, just to clarify, are you having problems copying the updated file or
opening your app once you've made sure that you have the most current file?

The command line will make a difference, especially if it has the /excl
switch on it. This opens the file exclusively. Where you looks in the
Options isn't what I was referring to. I was referring to the command line
used to open your app. It would be something like:

"<path>\msaccess.exe" "<path>\MyDatabase.mdb" /wrkrgp
"<path>\MyWorkgroup.mdw" /user UserName /pwd Password

What happens if you open the app without using the updater first, do the
problems go away? I suspect that the updater is locking the file for some
reason.

Thanks for the response:

[quoted text clipped - 62 lines]

Thank you for any ideas, suggestions,etc.

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

[Wayne Morgan]

Ok, this is probably a file copy problem then, not a database problem. What
is the updater app doing to check the files to see if you have the most
current one? What does it then do to copy the file from the share to your
computer? I suspect that it opens each file to check a version number in
them then tries to copy the newer file over the older one on your computer.
If it doesn't close each file properly after checking the version numbers,
the file may still be locked. While you may be able to copy the newer file
if it is open, it will depend on what state it was put in when opened, you
definitely will NOT be able to overwrite the older file on your computer
while the older file is still open.

The problem at this point may be the way the updater is opening and closing
the files or it may be that the "server" computer isn't closing the files
properly when the updater is done with them. Make sure that you have all of
the available updates from http://update.microsoft.com installed on both
computers. There have been some updates that will fix slow releases of
locked network files. You may also need to contact the person or company
that created the updater program.

Just to verify, when you open your database, you actually open the updater
program instead. It checks the file versions, it copies the newer one to
your computer if necessary, then it launches your database application. Is
this correct?

--
Wayne Morgan
MS Access MVP
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:60bc4db45ab07@uwe...

I was having trouble copying the update file. There are no /excl switches
on my command lines.

Opening the app is not the issue as it opens fine. It is copying down the
updated app to overwrite the existing app that is the problem. The error
causes a failure in the copying. Thereafter, the existing (non-updated
app)
opens just fine.

[rdemyan via AccessMonster.com]

I created the launching/update program. You're spot on as to the the method
for updating. Here's the code (I made a few changes to protect passwords,
etc):

'************************************************* ************************************************** ******************
Public Sub CheckforUpdates(LocalFile As String, ServerFile As String,
FileToBeUpdated As String)

'This routine checks for version updates to the front end and other modules:
The variable FileToBeUpdated contains 'the module name that will be updated.
It is used in the messagebox.

'1) Version number updates - checks the version numbers

On Error GoTo Err_Ctrl

Dim dbe As PrivDBEngine
Dim ws As DAO.Workspace, db As DAO.Database, rs As DAO.Recordset

Dim ServerVersion As String, LocalVersion As String
Dim UpdateFileName As String
Dim LocalDBType As String
Dim ServerDBType As String
Dim WorkgroupFileName As String
Dim X As Boolean
Dim Response As Integer

'First check the workgroup file
X = GetWorkGroupFile(WorkgroupFileName)

If X = False Then
MsgBox "Can't find the workgroup file. Cannot check for updates to MyApp.
", vbOKOnly + vbCritical
GoTo Exit_Sub
End If
'Now get the version numbers of both the local file and the
'server file (possible update file)

Set dbe = New PrivDBEngine

With dbe
' start Jet.
.SystemDB = WorkgroupFileName
.DefaultUser = "compact" 'This is an administrative User ID
.DefaultPassword = "mypassword"

' open workspace, database, recordset for Local File.
Set ws = .Workspaces(0)
Set db = ws.OpenDatabase(LocalFile)
Set rs = db.OpenRecordset("SELECT * FROM VersionRef", dbOpenSnapshot)
LocalDBType = Nz(rs("DB_TYPE"), "")
LocalVersion = Nz(rs("Version"), "")
rs.Close
db.Close

' open workspace, database, recordset for Server File.
Set ws = .Workspaces(0)
Set db = ws.OpenDatabase(ServerFile)
Set rs = db.OpenRecordset("SELECT * FROM VersionRef", dbOpenSnapshot)
ServerDBType = Nz(rs("DB_TYPE"), "")
ServerVersion = Nz(rs("Version"), "")
rs.Close
db.Close

End With

'Now compare versions
'Make sure only Jet versions are compared to Jet versions and SQL Server
versions
'to SQL Server versions
If ServerDBType = LocalDBType Then
If ServerVersion > LocalVersion Then

Response = MsgBox("A new version/update of " & FileToBeUpdated & " is
available." & vbCrLf & vbCrLf & _
"Click 'OK' to download the new version/update to your PC.",
vbOKCancel + vbExclamation)

If Response = vbCancel Then
GoTo Exit_Sub
End If

DoCmd.Hourglass True

Kill LocalFile
FileCopy ServerFile, LocalFile

'Pause for execution
DoEvents
Pause (5000)

DoCmd.Hourglass False

End If

End If
Exit_Sub:
DoCmd.Hourglass False
Set rs = Nothing
Set db = Nothing
Set ws = Nothing
Set dbe = Nothing

Exit Sub

Err_Ctrl:
DoCmd.Hourglass False
MsgBox "Error No. " & Err.Number & " -> " & Err.Description, vbCritical
Resume Exit_Sub

End Sub
'************************************************* ************************************************** ***

Thanks.

Wayne Morgan wrote:

Ok, this is probably a file copy problem then, not a database problem. What
is the updater app doing to check the files to see if you have the most
current one? What does it then do to copy the file from the share to your
computer? I suspect that it opens each file to check a version number in
them then tries to copy the newer file over the older one on your computer.
If it doesn't close each file properly after checking the version numbers,
the file may still be locked. While you may be able to copy the newer file
if it is open, it will depend on what state it was put in when opened, you
definitely will NOT be able to overwrite the older file on your computer
while the older file is still open.

The problem at this point may be the way the updater is opening and closing
the files or it may be that the "server" computer isn't closing the files
properly when the updater is done with them. Make sure that you have all of
the available updates from http://update.microsoft.com installed on both
computers. There have been some updates that will fix slow releases of
locked network files. You may also need to contact the person or company
that created the updater program.

Just to verify, when you open your database, you actually open the updater
program instead. It checks the file versions, it copies the newer one to
your computer if necessary, then it launches your database application. Is
this correct?

I was having trouble copying the update file. There are no /excl switches
on my command lines.

[quoted text clipped - 4 lines]

app)
opens just fine.

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

[Wayne Morgan]

Does the problem occur whether or not other users are also opening the
database on their computers? According to the help file, the default open
method when you use OpenDatabase() is shared. If the problem occurs when
others are also opening the database, you may want to try specifying False
for the option in case the default isn't working correctly.

If no other users are opening the file and you can only open the file the
first time you try after placing it in a new share then it sounds as if the
server computer isn't releasing the lock on the file when you close it. Go
to the server computer, right click My Computer and choose Manage. Under
System Tools go to Shared Folders then Open Files. Does it still show the
file as in use even though you've closed it?

Which line of code gives the problem, is it the OpenDatabase call? I show a
DBEngine object but not a PrivDBEngine object. What is the PrivDBEngine
object?

--
Wayne Morgan
MS Access MVP
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:60ce0b2bb12cc@uwe...

I created the launching/update program. You're spot on as to the the
method
for updating. Here's the code (I made a few changes to protect passwords,
etc):

'************************************************* ************************************************** ******************
Public Sub CheckforUpdates(LocalFile As String, ServerFile As String,
FileToBeUpdated As String)

'This routine checks for version updates to the front end and other
modules:
The variable FileToBeUpdated contains 'the module name that will be
updated.
It is used in the messagebox.

'1) Version number updates - checks the version numbers

On Error GoTo Err_Ctrl

Dim dbe As PrivDBEngine
Dim ws As DAO.Workspace, db As DAO.Database, rs As DAO.Recordset

Dim ServerVersion As String, LocalVersion As String
Dim UpdateFileName As String
Dim LocalDBType As String
Dim ServerDBType As String
Dim WorkgroupFileName As String
Dim X As Boolean
Dim Response As Integer

'First check the workgroup file
X = GetWorkGroupFile(WorkgroupFileName)

If X = False Then
MsgBox "Can't find the workgroup file. Cannot check for updates to
MyApp.
", vbOKOnly + vbCritical
GoTo Exit_Sub
End If
'Now get the version numbers of both the local file and the
'server file (possible update file)

Set dbe = New PrivDBEngine

With dbe
' start Jet.
.SystemDB = WorkgroupFileName
.DefaultUser = "compact" 'This is an administrative User ID
.DefaultPassword = "mypassword"

' open workspace, database, recordset for Local File.
Set ws = .Workspaces(0)
Set db = ws.OpenDatabase(LocalFile)
Set rs = db.OpenRecordset("SELECT * FROM VersionRef", dbOpenSnapshot)
LocalDBType = Nz(rs("DB_TYPE"), "")
LocalVersion = Nz(rs("Version"), "")
rs.Close
db.Close

' open workspace, database, recordset for Server File.
Set ws = .Workspaces(0)
Set db = ws.OpenDatabase(ServerFile)
Set rs = db.OpenRecordset("SELECT * FROM VersionRef", dbOpenSnapshot)
ServerDBType = Nz(rs("DB_TYPE"), "")
ServerVersion = Nz(rs("Version"), "")
rs.Close
db.Close

End With

'Now compare versions
'Make sure only Jet versions are compared to Jet versions and SQL Server
versions
'to SQL Server versions
If ServerDBType = LocalDBType Then
If ServerVersion > LocalVersion Then

Response = MsgBox("A new version/update of " & FileToBeUpdated & "
is
available." & vbCrLf & vbCrLf & _
"Click 'OK' to download the new version/update to your PC.",
vbOKCancel + vbExclamation)

If Response = vbCancel Then
GoTo Exit_Sub
End If

DoCmd.Hourglass True

Kill LocalFile
FileCopy ServerFile, LocalFile

'Pause for execution
DoEvents
Pause (5000)

DoCmd.Hourglass False

End If

End If
Exit_Sub:
DoCmd.Hourglass False
Set rs = Nothing
Set db = Nothing
Set ws = Nothing
Set dbe = Nothing

Exit Sub

Err_Ctrl:
DoCmd.Hourglass False
MsgBox "Error No. " & Err.Number & " -> " & Err.Description, vbCritical
Resume Exit_Sub

End Sub
'************************************************* ************************************************** ***

Thanks.

Wayne Morgan wrote:

Ok, this is probably a file copy problem then, not a database problem.
What
is the updater app doing to check the files to see if you have the most
current one? What does it then do to copy the file from the share to your
computer? I suspect that it opens each file to check a version number in
them then tries to copy the newer file over the older one on your
computer.
If it doesn't close each file properly after checking the version numbers,
the file may still be locked. While you may be able to copy the newer file
if it is open, it will depend on what state it was put in when opened, you
definitely will NOT be able to overwrite the older file on your computer
while the older file is still open.

The problem at this point may be the way the updater is opening and
closing
the files or it may be that the "server" computer isn't closing the files
properly when the updater is done with them. Make sure that you have all
of
the available updates from http://update.microsoft.com installed on both
computers. There have been some updates that will fix slow releases of
locked network files. You may also need to contact the person or company
that created the updater program.

Just to verify, when you open your database, you actually open the updater
program instead. It checks the file versions, it copies the newer one to
your computer if necessary, then it launches your database application. Is
this correct?

I was having trouble copying the update file. There are no /excl
switches
on my command lines.

[quoted text clipped - 4 lines]

app)
opens just fine.

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

[rdemyan via AccessMonster.com]

The problem occurs at the FileCopy line of code.

To be honest, I don't know where I got the PrivDBEngine object. I had never
seen it before either. I got the code from somewhere and then customized it
to meet my needs. I was developing and still am developing in A2K. I only
started to get this problem when I started trying to run my app on A2003
because I anticipate that all users will soon be upgraded.

Wayne Morgan wrote:

Does the problem occur whether or not other users are also opening the
database on their computers? According to the help file, the default open
method when you use OpenDatabase() is shared. If the problem occurs when
others are also opening the database, you may want to try specifying False
for the option in case the default isn't working correctly.

If no other users are opening the file and you can only open the file the
first time you try after placing it in a new share then it sounds as if the
server computer isn't releasing the lock on the file when you close it. Go
to the server computer, right click My Computer and choose Manage. Under
System Tools go to Shared Folders then Open Files. Does it still show the
file as in use even though you've closed it?

Which line of code gives the problem, is it the OpenDatabase call? I show a
DBEngine object but not a PrivDBEngine object. What is the PrivDBEngine
object?

I created the launching/update program. You're spot on as to the the
method

[quoted text clipped - 152 lines]

app)
opens just fine.

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

[Terry Kreft]

From
http://www.microsoft.com/technet/pro....mspx?mfr=true
"Using Private DBEngine Objects
One advantage that Microsoft Visual C++ and Visual Basic developers have
over Microsoft Access developers is that when their program starts, the
DBEngine object isn't yet initialized. This allows the program to set
important properties such as the SystemDB property (which sets or returns
the path for the current location of the workgroup information file), and
the DefaultUser and DefaultPassword properties (which set the user name and
password to use for default logon). In Microsoft Access, however, the
DBEngine object is already initialized when you start, and none of these
properties can be changed. Even in Visual Basic, you may want to open a
database that uses a different workgroup information file, without having to
start a new application through Automation to do so.

There is a new object called a PrivDBEngine object, which is a new,
uninitialized copy of the top-level DBEngine object, with its own objects
and collections beneath it. You can use the PrivDBEngine object to open a
database that uses a different workgroup information file, to determine
whether a database is opened exclusively, and to determine whether you can
open a database exclusively.

To create a private DBEngine object, declare an object variable as type
PrivDBEngine, and then use the Set statement with the New keyword, as shown
in the following code:

Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine"

--

Terry Kreft
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:60e984dae6e2d@uwe...

The problem occurs at the FileCopy line of code.

To be honest, I don't know where I got the PrivDBEngine object. I had never seen it before either. I got the code from somewhere and then customized it to meet my needs. I was developing and still am developing in A2K. I only started to get this problem when I started trying to run my app on A2003
because I anticipate that all users will soon be upgraded.

Wayne Morgan wrote:

Does the problem occur whether or not other users are also opening the
database on their computers? According to the help file, the default open
method when you use OpenDatabase() is shared. If the problem occurs when
others are also opening the database, you may want to try specifying Falsefor the option in case the default isn't working correctly.

If no other users are opening the file and you can only open the file the
first time you try after placing it in a new share then it sounds as if theserver computer isn't releasing the lock on the file when you close it. Goto the server computer, right click My Computer and choose Manage. Under
System Tools go to Shared Folders then Open Files. Does it still show the
file as in use even though you've closed it?

Which line of code gives the problem, is it the OpenDatabase call? I show aDBEngine object but not a PrivDBEngine object. What is the PrivDBEngine
object?

I created the launching/update program. You're spot on as to the the
method

[quoted text clipped - 152 lines]

> app)
> opens just fine.

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

[Wayne Morgan]

Thanks Terry, that wasn't in the help file.

Rdemyan,
As a test, let's check the macro security settings in A2003. Go to
Tools|Macro|Security and on the Security Level tab set it at Low. See if
this makes a difference.

Is your loader app written in Access or something else? Have you checked the
file locks on the server computer?

--
Wayne Morgan
MS Access MVP
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:0F********************@karoo.co.uk...

From
http://www.microsoft.com/technet/pro....mspx?mfr=true
"Using Private DBEngine Objects
One advantage that Microsoft Visual C++ and Visual Basic developers have
over Microsoft Access developers is that when their program starts, the
DBEngine object isn't yet initialized. This allows the program to set
important properties such as the SystemDB property (which sets or returns
the path for the current location of the workgroup information file), and
the DefaultUser and DefaultPassword properties (which set the user name
and
password to use for default logon). In Microsoft Access, however, the
DBEngine object is already initialized when you start, and none of these
properties can be changed. Even in Visual Basic, you may want to open a
database that uses a different workgroup information file, without having
to
start a new application through Automation to do so.

There is a new object called a PrivDBEngine object, which is a new,
uninitialized copy of the top-level DBEngine object, with its own objects
and collections beneath it. You can use the PrivDBEngine object to open a
database that uses a different workgroup information file, to determine
whether a database is opened exclusively, and to determine whether you can
open a database exclusively.

To create a private DBEngine object, declare an object variable as type
PrivDBEngine, and then use the Set statement with the New keyword, as
shown
in the following code:

Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine"

[rdemyan via AccessMonster.com]

Wayne, appreciate your sticking this out with me. Thank you.

1) Security in A2003 had been set to Low all along.
2) Loader app is an Access application.

3) I don't know how to check file locks. The "server' computer is just a
laptop running Windows XP Home edition. I'm just using it to simulate a
server (to work out bugs, etc) before the app gets distributed.

4) I just tried running the launcher app on A2003. The launcher now looks
for updates for two small apps that work in conjunction with my main
application. In my first post it was the main application that was causing
the problem. Today it was updated just fine on A2003 (download of a newer
version from the "server"). However, the other two apps gave the "exclusive"
error message that I mentioned at the beginning of this thread. The "update"
code checks to make sure that the file on the server exists (using file
scripting). In all cases, files have always existed on the "server". Also,
the "update" code that I posted earlier is what is being used to check for
updates on all applications (main application and two smaller apps.)

NOTE: I was wrong in previous posts on where the error occurs. It is
occurring on the following line:

Set db = ws.OpenDatabase(ServerFile)

SO: I did what I did earlier. I created a new main folder on the "server".
I also created new subfolders, i.e. "Update". Then I copied the update files
from the old subfolder into the new subfolder. Next I went to the launching
program on A2003 and changed the location for the launcher to check for
updates to the new folder/subfolder that I just created on the "server".
Everything worked just fine. The launcher brought up a message saying that
updates for the two smaller apps had been found and asking if I wanted to
download them. I responded 'Yes' and everything downloaded just fine.

Do you think the problem might be with the dbe object? Maybe I should close
it after checking the local file and then reset it to check the server file.
The issues is that this is not a consistently reproducible problem.

Again, I've never had this problem with A2000.

Thanks.



Wayne Morgan wrote:

Thanks Terry, that wasn't in the help file.

Rdemyan,
As a test, let's check the macro security settings in A2003. Go to
Tools|Macro|Security and on the Security Level tab set it at Low. See if
this makes a difference.

Is your loader app written in Access or something else? Have you checked the
file locks on the server computer?

From
http://www.microsoft.com/technet/pro....mspx?mfr=true

[quoted text clipped - 27 lines]

Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine"

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

[rdemyan via AccessMonster.com]

Something that just occurred to me that I should have realized earlier. The
same main folder on the server that has the subfolder, "Updates", which is
what my launching program has exclusivity problems with, also has a subfolder
called Back-ends. This "server" folder contains the back-end files that my
app links to. I haven't had any problems linking to the back-end files.
Since these back-end files are linked to using OpenDatabase as well, maybe
the problem is with the PrivDBEngine. The backend files are linked to using
the regular DAO objects, not PrivDBEngine.

Maybe I need to just use regular DAO workspace and database objects. I guess
the advantage of PrivDBEngine was being able to use SystemDB, DefaultUser and
DefaultPassword properties. Maybe there's another way I could do this. Once
my mainapp is opened, I've already logged on so I guess that's why using the
regular DAO objects works (the back-end files also use the same workgroup
file as the mainapp). However, in the launching program, I'm checking for
updates before logging into the workgroup file and I'm using an
"administrative user and password" to do it.

I just tried changing the DefaultUser and DefaultPassword to that of the
"Owner" of the applications and back-end files. Same problem with
exclusivity.

So maybe what I need to do is to find a different way to open these files to
check for the version numbers.

rdemyan wrote:

Wayne, appreciate your sticking this out with me. Thank you.

1) Security in A2003 had been set to Low all along.
2) Loader app is an Access application.

3) I don't know how to check file locks. The "server' computer is just a
laptop running Windows XP Home edition. I'm just using it to simulate a
server (to work out bugs, etc) before the app gets distributed.

4) I just tried running the launcher app on A2003. The launcher now looks
for updates for two small apps that work in conjunction with my main
application. In my first post it was the main application that was causing
the problem. Today it was updated just fine on A2003 (download of a newer
version from the "server"). However, the other two apps gave the "exclusive"
error message that I mentioned at the beginning of this thread. The "update"
code checks to make sure that the file on the server exists (using file
scripting). In all cases, files have always existed on the "server". Also,
the "update" code that I posted earlier is what is being used to check for
updates on all applications (main application and two smaller apps.)

NOTE: I was wrong in previous posts on where the error occurs. It is
occurring on the following line:

Set db = ws.OpenDatabase(ServerFile)

SO: I did what I did earlier. I created a new main folder on the "server".
I also created new subfolders, i.e. "Update". Then I copied the update files
from the old subfolder into the new subfolder. Next I went to the launching
program on A2003 and changed the location for the launcher to check for
updates to the new folder/subfolder that I just created on the "server".
Everything worked just fine. The launcher brought up a message saying that
updates for the two smaller apps had been found and asking if I wanted to
download them. I responded 'Yes' and everything downloaded just fine.

Do you think the problem might be with the dbe object? Maybe I should close
it after checking the local file and then reset it to check the server file.
The issues is that this is not a consistently reproducible problem.

Again, I've never had this problem with A2000.

Thanks.

Thanks Terry, that wasn't in the help file.

[quoted text clipped - 11 lines]

Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine"

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

[Wayne Morgan]

To check the locks, you can use the method I mentioned a couple of messages
ago. Right click My Computer on the server computer and choose Manage. In
the left pane go to System Tools|Shared Folders|Open Files and see if the
file is listed in the right pane as being open even though you've supposedly
closed it.

The fact that it works when you move it tells me that something is keeping a
lock on the file even though it appears you've closed the file. Moving the
file creates a "new" file that hasn't been locked yet.

--
Wayne Morgan
MS Access MVP

[Wayne Morgan]

I would be willing to try it here to see if the same problem exists if you
don't mind zipping the files and sending me a copy. If so, send them to
co*****@hotmail.com.

--
Wayne Morgan
MS Access MVP

[rdemyan via AccessMonster.com]

Appreciate the offer, but it's not a possibility.

I think I'm going to try using CreateWorkspace instead and see if that works.
Currently I'm on the road, so it will be a few days. I'll report back on the
results.

Thanks again for your help!

Wayne Morgan wrote:

I would be willing to try it here to see if the same problem exists if you
don't mind zipping the files and sending me a copy. If so, send them to
co*****@hotmail.com.

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

[rdemyan via AccessMonster.com]

I followed the following post:

http://www.accessmonster.com/Uwe/For...Thanks-to-Paul
Everything works fine now. I tested this by keeping the old CheckforUpdates
procedure and switching between the new code and the old code. The old code
failed as usual, but the new code was able to successfully open the files to
check the version numbers.

The code that Paul posted combines both the PrivDBEngine and CreateWorkspace.

Thanks!!

rdemyan wrote:

Appreciate the offer, but it's not a possibility.

I think I'm going to try using CreateWorkspace instead and see if that works.
Currently I'm on the road, so it will be a few days. I'll report back on the
results.

Thanks again for your help!

I would be willing to try it here to see if the same problem exists if you
don't mind zipping the files and sending me a copy. If so, send them to
co*****@hotmail.com.

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

[Wayne Morgan]

Great. Thanks for posting what does work.

--
Wayne Morgan
MS Access MVP
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:6133cf23d63f9@uwe...

I followed the following post:

http://www.accessmonster.com/Uwe/For...Thanks-to-Paul
Everything works fine now. I tested this by keeping the old
CheckforUpdates
procedure and switching between the new code and the old code. The old
code
failed as usual, but the new code was able to successfully open the files
to
check the version numbers.

The code that Paul posted combines both the PrivDBEngine and
CreateWorkspace.