Updating users front ends via VBA (1 Viewer)

Gasman

Enthusiastic Amateur
Local time
Today, 16:56
Joined
Sep 21, 2011
Messages
14,044
Nope. Trying to run anything causes the app to crash out.
Maybe its because it is for I believe an older version of Access? Aren't MDB files for 2010 and older?

Edit:
For the record, I am running 2016 with no access (no pun intended) to older versions
If you look at the code, you can do it manually? perhaps @Minty can create a later version in accdb format.
The code inserts some tables into yours, so if it has the same problems I have with later dbs' then it might fail on that.?
The main code I posted previously and that you can copy as well.?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 09:56
Joined
Oct 29, 2018
Messages
21,358
Nope. Trying to run anything causes the app to crash out.
Maybe its because it is for I believe an older version of Access? Aren't MDB files for 2010 and older?

Edit:
For the record, I am running 2016 with no access (no pun intended) to older versions
In that case, I will repeat my earlier request. Can you provide a copy of your own file, so we can try to fix it?

I'm afraid if I try to fix somebody else's file, you might still ask us to apply the fix to your own file. So, if we can avoid doing the same work twice, I would appreciate it.

Just my 2 cents...
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
In that case, I will repeat my earlier request. Can you provide a copy of your own file, so we can try to fix it?

I'm afraid if I try to fix somebody else's file, you might still ask us to apply the fix to your own file. So, if we can avoid doing the same work twice, I would appreciate it.

Just my 2 cents...
What I grabbed from Minty.
 

Attachments

  • Access_Front-End_AutoUpdating_Utility_Backup.mdb
    520 KB · Views: 149

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:56
Joined
Feb 28, 2001
Messages
26,999
There seems to be a few problems here. First problem - doing this from within Access can lead to 32/64 bit complaints. Second, once Access is open on an App and your app remains in control, any version you copy won't be used until the next instance of the app is launched.

There are such things as batch/script updaters that don't care about versioning. If you take the approach of ALWAYS copying the latest version from the designated pick-up area, there are no issues with 32/64 bit in the update process.

However, THIRD problem: There is still the idea that you might be running into a non-homogeneous work environment in which some folks have 32-bit Office and some have 64-bit Office. That is a different kettle of fish. If you develop for a 64-bit Office environment, a lot of the "standard 32-bit" library becomes either useless or of limited value without some work. But if you develop for a 32-bit Office environment and your targets have only the 64-bit Office environment, they won't have all of the required .DLL files installed and registered. Note that I am not making a comment about having 64-bit WINDOWS. I have that and my 32-bit Office runs just fine. It is specifically the bitness of the target machine environments vs. the bitness of the development environment.
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:56
Joined
Sep 21, 2011
Messages
14,044
Here is my last attempt.
I put conditional compiler directives where I thought they were needed and save as an accdb.
It does compile for me.?
 

Attachments

  • Access_Front-End_AutoUpdating_Utility.accdb
    532 KB · Views: 148

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
There seems to be a few problems here. First problem - doing this from within Access can lead to 32/64 bit complaints. Second, once Access is open on an App and your app remains in control, any version you copy won't be used until the next instance of the app is launched.

There are such things as batch/script updaters that don't care about versioning. If you take the approach of ALWAYS copying the latest version from the designated pick-up area, there are no issues with 32/64 bit in the update process.

However, THIRD problem: There is still the idea that you might be running into a non-homogeneous work environment in which some folks have 32-bit Office and some have 64-bit Office. That is a different kettle of fish. If you develop for a 64-bit Office environment, a lot of the "standard 32-bit" library becomes either useless or of limited value without some work. But if you develop for a 32-bit Office environment and your targets have only the 64-bit Office environment, they won't have all of the required .DLL files installed and registered. Note that I am not making a comment about having 64-bit WINDOWS. I have that and my 32-bit Office runs just fine. It is specifically the bitness of the target machine environments vs. the bitness of the development environment.
That is very informative. I would have assumed bits referred to windows and not the app itself.
As far as everything else goes, this will be on company computers and our IT keeps all computers in sync as far as versions and such goes. So what I am working with is what everyone else will have as well thankfully.

In all honesty, I am only going to have at absolute most, 8 concurrent users. It wouldn't be that big of a hassle to go around and manually put the right version of their computer. We have another app that was built in house by someone else, and that poor girl has to go around with a thumb drive and update ~50 computers.
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:56
Joined
Sep 21, 2011
Messages
14,044
That is very informative. I would have assumed bits referred to windows and not the app itself.
As far as everything else goes, this will be on company computers and our IT keeps all computers in sync as far as versions and such goes. So what I am working with is what everyone else will have as well thankfully.

In all honesty, I am only going to have at absolute most, 8 concurrent users. It wouldn't be that big of a hassle to go around and manually put the right version of their computer. We have another app that was built in house by someone else, and that poor girl has to go around with a thumb drive and update ~50 computers.
Well, when you get this working, you can show her how it is done? :) though she will have to do it just once more to get the new version installed.? I just asked my lot to click a shortcut on the server which installed the very first version for them.
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
Here is my last attempt.
I put conditional compiler directives where I thought they were needed and save as an accdb.
It does compile for me.?
Didn't work 😭. Same bit error.
Dont worry about it anymore Gas. I will keep doing research and figure it out. I am still messing with the code I got from your Github post :)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:56
Joined
Feb 19, 2002
Messages
42,971
This is a simple process if you use a batch file.
Code:
md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb

Put the .bat file in the directory on the server where you will keep your "master" version of the FE. Have each user create (or you send to him) a shortcut that they put on their desktop that runs the batch file. The .bat file has no error trapping because it doesn't need any as long as there is always a copy of your FE in the server directory. If the local directory already exists, no error is raised. If the local copy of the FE is not found by the delete command, no problem. No error is raised.

No need to worry about bit-wise Office or Access version. Very Simple. If you are using Citrix, it's still the same four commands but the reference to the directories must be different since they would be dependent on the user's id.

As the example shows, use the UNC path when referencing the server. That way you don't need to worry about a mapped drive.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:56
Joined
Feb 28, 2001
Messages
26,999
Thanks, Pat. I had somehow misplaced my reference to that snippet. I've been a bit distracted lately.
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
This is a simple process if you use a batch file.
Code:
md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb

Put the .bat file in the directory on the server where you will keep your "master" version of the FE. Have each user create (or you send to him) a shortcut that they put on their desktop that runs the batch file. The .bat file has no error trapping because it doesn't need any as long as there is always a copy of your FE in the server directory. If the local directory already exists, no error is raised. If the local copy of the FE is not found by the delete command, no problem. No error is raised.

No need to worry about bit-wise Office or Access version. Very Simple. If you are using Citrix, it's still the same four commands but the reference to the directories must be different since they would be dependent on the user's id.

As the example shows, use the UNC path when referencing the server. That way you don't need to worry about a mapped drive.
I am going to have to read up on batch files. This seems pretty nice and straight forward though.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:56
Joined
Feb 19, 2002
Messages
42,971
.bat files are a leftover from the DOS days but still supported by Windows. Windows has a more sophisticated scripting language which is what NauticalGent's link pointed to.
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
.bat files are a leftover from the DOS days but still supported by Windows. Windows has a more sophisticated scripting language which is what NauticalGent's link pointed to.
I just made one, and to my surprise our security settings didnt stomp all over it.
Questions though, is having cmdpromt not pop up possible? It also deleted the file, but did not place a replacement, so i must have made a mistake.
Code:
md C:\Users\tmyers\Desktop
del C:\Users\tmyers\Desktop\Quotations.accdr
copy "desktop\PM DESKTOP FILES\Lighting Project Management Application\Quotations.accdr" C:\Users\tmyers\Desktop
C:\Users\tmyers\Desktop\Quotations.accdr
I deleted part of the path to the server computer out just in case.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:56
Joined
Feb 19, 2002
Messages
42,971
There might be a way to run the file as hidden. But, I would have to search the internet for a source that defines the batch file instructions and I'm about to start a bridge game so you'll need to search yourself. I'll try to remember to come back later so let us know if you find what you are looking for.
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
There might be a way to run the file as hidden. But, I would have to search the internet for a source that defines the batch file instructions and I'm about to start a bridge game so you'll need to search yourself. I'll try to remember to come back later so let us know if you find what you are looking for.
I was actually able to find it already. Was easier found then I though.
I will have to research how to handle this when the user is different. Probably have to deal with strings and variables and what not.
Enjoy your game pat!
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:56
Joined
Sep 21, 2011
Messages
14,044
I have something on my old works server. I'll try and dig it out tomorrow, if it helps?
Plus I do not think you need to delete the file as it gets overwritten without any issue?
 
Last edited:

Gasman

Enthusiastic Amateur
Local time
Today, 16:56
Joined
Sep 21, 2011
Messages
14,044
Seems I used VBS
Code:
Const DESKTOP = &H10&
'DIM strDBPath as string, strLnk as string, strFilePath as string
strDBPath = "C:\DB\"
strLnk = "\\srvph\jagph\DB\Employee DB.lnk"
strDB = "\\srvph\jagph\DB\Employee.accde"
Set objFSO      = CreateObject("Scripting.FileSystemObject")
Set objAppshell = CreateObject("Shell.Application")
Set objFolder = objAppShell.Namespace(DESKTOP)
strFilePath = objFolder.Self.Path & "\"
objFSO.CopyFile strlnk,strFilePath,True
MSGBOX "Shortcut copied to " & strFilePath,0,"Install Employee Shortcut"
IF NOT (objFSO.FolderExists(strDBPath)) then
    strPath = objFSO.CreateFolder("C:\DB")
End if
objFSO.CopyFile strDB,strDBpath,True
MSGBOX "Employee DB copied to " & strDBPath,0,"Install Employee DB"
set objFSO = Nothing
Set objAppShell = Nothing
Set objFolder = Nothing
This was the install script and then from then on I used the FE Updater?
You could use this to install the accdr file after mods.?
 

tmyers

Well-known member
Local time
Today, 12:56
Joined
Sep 8, 2020
Messages
1,090
I figured it out with a little help. I also got the cmd prompt window to close out how i wanted.
 

Users who are viewing this thread

Top Bottom