MS Access Forum / General 1 / June 2006
Unable to access folder from A2003
|
|
Thread rating:  |
rdemyan - 22 May 2006 15:14 GMT 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.
Wayne Morgan - 22 May 2006 16:05 GMT 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)?
 Signature Wayne Morgan MS Access MVP
> 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. rdemyan - 22 May 2006 16:44 GMT 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.
>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 [quoted text clipped - 9 lines] >> >> Thank you for any ideas, suggestions,etc. Wayne Morgan - 23 May 2006 22:03 GMT 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.
 Signature Wayne Morgan MS Access MVP
> Thanks for the response: > [quoted text clipped - 62 lines] >>> >>> Thank you for any ideas, suggestions,etc. rdemyan - 24 May 2006 16:56 GMT 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.
>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? [quoted text clipped - 16 lines] >>>> >>>> Thank you for any ideas, suggestions,etc. Wayne Morgan - 25 May 2006 19:17 GMT 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?
 Signature Wayne Morgan MS Access MVP
>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. rdemyan - 26 May 2006 02:48 GMT 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.
>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 [quoted text clipped - 25 lines] >> app) >> opens just fine. Wayne Morgan - 27 May 2006 06:04 GMT 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?
 Signature Wayne Morgan MS Access MVP
>I created the launching/update program. You're spot on as to the the >method [quoted text clipped - 152 lines] >>> app) >>> opens just fine. rdemyan - 28 May 2006 07:15 GMT 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.
>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 [quoted text clipped - 18 lines] >>>> app) >>>> opens just fine. Terry Kreft - 28 May 2006 18:50 GMT From http://www.microsoft.com/technet/prodtechnol/sql/70/proddocs/msjet/jetch02.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"
 Signature Terry Kreft
> The problem occurs at the FileCopy line of code. > [quoted text clipped - 26 lines] > >>>> app) > >>>> opens just fine. Wayne Morgan - 30 May 2006 11:01 GMT 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?
 Signature Wayne Morgan MS Access MVP
> From > http://www.microsoft.com/technet/prodtechnol/sql/70/proddocs/msjet/jetch02.mspx? mfr=true [quoted text clipped - 27 lines] > > Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine" rdemyan - 30 May 2006 15:09 GMT 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" rdemyan - 30 May 2006 16:40 GMT 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.
>Wayne, appreciate your sticking this out with me. Thank you. > [quoted text clipped - 43 lines] >>> >>> Dim dbe As PrivDBEngine Set dbe = New PrivDBEngine" Wayne Morgan - 30 May 2006 22:50 GMT 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.
 Signature Wayne Morgan MS Access MVP
Wayne Morgan - 30 May 2006 22:52 GMT 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 comprev@hotmail.com.
 Signature Wayne Morgan MS Access MVP
rdemyan - 31 May 2006 14:56 GMT 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 >comprev@hotmail.com. rdemyan - 03 Jun 2006 05:03 GMT I followed the following post:
http://www.accessmonster.com/Uwe/Forum.aspx/access-security/6290/Assign-a-workgr oup-to-a-workspace-object-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!!
>Appreciate the offer, but it's not a possibility. > [quoted text clipped - 7 lines] >>don't mind zipping the files and sending me a copy. If so, send them to >>comprev@hotmail.com. Wayne Morgan - 06 Jun 2006 11:01 GMT Great. Thanks for posting what does work.
 Signature Wayne Morgan MS Access MVP
>I followed the following post: > [quoted text clipped - 10 lines] > The code that Paul posted combines both the PrivDBEngine and > CreateWorkspace.
|
|
|