pcalabria
asked on
Need a way to programmatically start an MS Access mde from a second MS Access mde
Need a way to programmatically close an MS Access database and programmatically open another.
Each user has an MS Access application that I call MyProgram.mde on the workstation local hard drive (10 users).
Each time I roll out a new version MyProgram.mde all I need to do is copy the new version to a network drive.
The users start MyProgram.mde each day by clicking a shortcut to another program called BootStrapLoader, which is also on the local drive.
When BootStrapLoader starts, it compares two fields, on in each version of MyProgram, to determine whether the code on the network drive is a higher version number.
When it finds a higher version number on the network drive, it copies that version of MyProgram.mde to the local drive, overwriting the old version.
Then, after a delay that I add to allow for the file to copy, BootStrapLoader closes and also starts MyProgram.mde.
When the copy on the network drive is the same version, BootStrapLoader closes and then starts the program on the local drive.
To accomplish this, I have been using a program called TsiSoon90.dll, which is something that someone on this forum told me about many years ago, and has worked very well on our XP machines.
We are now upgrading to 64-bit Win7 and Win10 machines, and the 32-bit version of TSIsoon90.dll does not register. I suspect this a 32 vs 64 bit issue.
Does anyone know how to get this to work on Win7 or Win10 64-bit machines, or have another solution?
I would really appreciate your help. Thanks
Each user has an MS Access application that I call MyProgram.mde on the workstation local hard drive (10 users).
Each time I roll out a new version MyProgram.mde all I need to do is copy the new version to a network drive.
The users start MyProgram.mde each day by clicking a shortcut to another program called BootStrapLoader, which is also on the local drive.
When BootStrapLoader starts, it compares two fields, on in each version of MyProgram, to determine whether the code on the network drive is a higher version number.
When it finds a higher version number on the network drive, it copies that version of MyProgram.mde to the local drive, overwriting the old version.
Then, after a delay that I add to allow for the file to copy, BootStrapLoader closes and also starts MyProgram.mde.
When the copy on the network drive is the same version, BootStrapLoader closes and then starts the program on the local drive.
To accomplish this, I have been using a program called TsiSoon90.dll, which is something that someone on this forum told me about many years ago, and has worked very well on our XP machines.
We are now upgrading to 64-bit Win7 and Win10 machines, and the 32-bit version of TSIsoon90.dll does not register. I suspect this a 32 vs 64 bit issue.
Does anyone know how to get this to work on Win7 or Win10 64-bit machines, or have another solution?
I would really appreciate your help. Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In the past, I've created simple VB projects that I use as my "loader". The user runs the "loader", and all it does is check the versions. If it needs a new file, then the loader copies it, then launches. If not, then it just launches the local file.
I also used the loader to relink and such, but it doesn't have to do that.
You can create a loader in Access, but it's better (IMO) to do it in a different environment, like .NET.
Have you tried using OpenCurrentDatabase:
DAO.OpenCurrentDatabase "the path to your local database"
That may do what you want, in a roundabout way. It would open the local database in the current instance of Access, which may do what you're after.
I also used the loader to relink and such, but it doesn't have to do that.
You can create a loader in Access, but it's better (IMO) to do it in a different environment, like .NET.
Have you tried using OpenCurrentDatabase:
DAO.OpenCurrentDatabase "the path to your local database"
That may do what you want, in a roundabout way. It would open the local database in the current instance of Access, which may do what you're after.
ASKER
Scott.. I got tied up with bigger fires but I will definitely try this solution as soon as I can.
My BootStraploader program and your loader program seem very similar. Do you remember how you did it and did you use tsisoon90.dll?
As far as .Net, I don't speak that language..:-(
My BootStraploader program and your loader program seem very similar. Do you remember how you did it and did you use tsisoon90.dll?
As far as .Net, I don't speak that language..:-(
I did not use tsisoon. If I recall, it was written in VB6, and all it did was check the version number stored in a predefined location (I believe I used the Registry, but you could use a text file, or a database), and compare that with the version number of the local database. If they differed, I copied the new file to the machine. I then launched the FE file with a standard command line:
"full path to msaccess.exe" "full path to the local database file"
The loader needed a few bits of information:
1. The location of the "version check" file
2. The location of the new FE, in case a copy was needed
3. The location of msaccess.exe on the local machine
4. The location where the FE was stored on the local machine
I set those up for each machine, and the loader did the rest.
"full path to msaccess.exe" "full path to the local database file"
The loader needed a few bits of information:
1. The location of the "version check" file
2. The location of the new FE, in case a copy was needed
3. The location of msaccess.exe on the local machine
4. The location where the FE was stored on the local machine
I set those up for each machine, and the loader did the rest.
ASKER
Thanks for your help.
I never did get TSIsoon working on my 64-bit machines.
I solved the problem by using a batch file to copy the new version from the server,
and then issued a command to start a new instance of ms access, by using the shell command.
Do the the path differences between early and current versions of office I added the following code, allowing me to easily make changes as different file locations are used.
strPath1 = "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE "
strPath2 = "C:\Program Files (x86)\Microsoft Office\Office\MSACCESS.EXE "
strPath = ""
If Dir(strPath1) <> "" Then
strPath = strPath1
End If
If Dir(strPath2) <> "" Then
strPath = strPath2
End If
If strPath = "" Then
MsgBox "Unable to find MSACCESS.EXE in path" & vbCrLf & vbCrLf & "Checked: " & strPath1 & vbCrLf & "Checked: " & strPath2
GoTo ExitRoutine
End If
strParameter = "C:\Disti-Master\Database\ Inventory_ Program.md e"
Call Shell(strPath & " " & strParameter)
ExitRoutine:
DoCmd.Quit
Exit Sub
I never did get TSIsoon working on my 64-bit machines.
I solved the problem by using a batch file to copy the new version from the server,
and then issued a command to start a new instance of ms access, by using the shell command.
Do the the path differences between early and current versions of office I added the following code, allowing me to easily make changes as different file locations are used.
strPath1 = "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE
strPath2 = "C:\Program Files (x86)\Microsoft Office\Office\MSACCESS.EXE
strPath = ""
If Dir(strPath1) <> "" Then
strPath = strPath1
End If
If Dir(strPath2) <> "" Then
strPath = strPath2
End If
If strPath = "" Then
MsgBox "Unable to find MSACCESS.EXE in path" & vbCrLf & vbCrLf & "Checked: " & strPath1 & vbCrLf & "Checked: " & strPath2
GoTo ExitRoutine
End If
strParameter = "C:\Disti-Master\Database\
Call Shell(strPath & " " & strParameter)
ExitRoutine:
DoCmd.Quit
Exit Sub
ASKER
It seems strange to me that this should be so complicated! The bootstraploader program can easily copy the new application file to the local machine.....so all I really need to do is have my access application start another instance of access and then close itself... Hopefully one of the experts here will have an idea!
Yes, Mich Kaplan's dll has given me good use throughout the years!