Best practice to roll out updated FE:s

Question

Hi

What is the best way to roll out updated database on multiple Windows 2012 R installations (remote desktop)? BE is the same on all machines and FE is also identical. Want UNC connections between FE and BE. A customer may have an FE other customers have between two and five FE. The number of customers are groving and time for updating all instances take too much time.

Both FE and BE in is the same folder.

Any ideas or good examples?

---

Cheers // Peter Forss Stockholm

Answer 1

Well for sure you want each customer to download their own FE file(s) as needed. I would just put the various FE's in a Shared directory or in a One Drive folder or other file share service location and send each customer a link to where the FE's are located. They can then download their own FE's to their own machines. No customer should ever share a FE file on a shared drive. 

Answer 2

My approach is best described in three parts:

1. As all my software is distributed via my website, the first task is to alert the program admins (PAs) at each client site of any updates. To do this automatically, I build a web version checker into all my commercial applications. This runs at start-up for the client PAs only, alerts them if a newer version is available to download and provides the link to do so.

See Web Version Checker for further details and an example app

2. Once the updated version has been downloaded at a convenient time of their choosing, the client PA runs the update (.EXE file) which automatically relinks the new FE to the client BEs and runs any related code required for the update to be used. The updated FE is then moved to a designated folder on the network.

3. When end users run the application(s) from desktop shortcut, they see a small splash screen. In fact they are actually opening a small file which checks for a newer version on the local network.

If the current version is the latest, the main file is then opened. If a newer version exists, this is automatically downloaded to the users' workstations and then opened. This takes less than 5 seconds as an API is used to transfer files from the network at high speed. The process is seamless and guarantees users are always running the latest version available.

Hope that makes sense

Happy to provide further details if required

Answer 3

the org I work for has set up a system/shell batch - - that when users log on it downloads the current released FE to their virtual desktop.  I did not write this system/shell batch.

as the Access app developer when I put out a new release - I assure that the name is always unchanged (i.e. no version in the file name) and that I put it in a specific folder.  Then  each user will get this release the next time they log on....and by this I mean not just close/reopen Access/App but actually shut down and restart the virtual Pc.

we release only an .accde and the user base is all now 365 with full license - - however we've been doing this style for ~10 yrs or so back when most had only the runtime license and no one was remote.......and it works the same for those actually in the office using PCs as well as remote users....

Answer 4

I have to deploy one particular FE to half a dozen servers with hundreds of users.

This means hosting the BE on a SQL Server if its over a network. Access BE couldn't handle the load.

To deliver the FE I wrote a very basic C# Windows app specifically for my environment. I chose to do this instead of a script only because I'm more familiar with C#. I place this app in a folder on the C:\ drive somewhere. Then I put a shortcut on the Public Desktops of the servers. so every user has access to it.

I have network shares to those 6 servers. I place a copy of the FE in that share for all 6 servers whenever I publish an update. Copying over a site to site VPN is a little slow, so for UX I copy it myself to the servers. Somewhere like C:\MSA\temp\MSASourceFE\MyProject.accde

When a user clicks the shortcut, my C# app looks in that folder for the most updated FE I placed there. It makes a copy and stores it in a temp folder for the user. Then it executes the copy and opens it for the user. That way the user never needs to interact with the access file or look for an updated FE themselves.

The App I created also deletes all temp folder content before copying a new version. These FEs allow the users to download images they only need for a short time, so I store them in the temp folder too. Its a easy clean up process. And ensures fresh FEs.

Answer 5

Thank you all for inspiring me.

Lets say:

1 there is a server based on Windows Server 2012 R2. Users accesing it as a remote desktop.

2 There are four accounts, one per customer. A customer is a company.

3 Each customer have 1 to many users

4 The BE access file is in a folder with the path P:\data (or \\BADC\NameOfCompany\data\)

5 The FE files should be in the same folder as on 4, \\BADC\NameOfCompany\data\

6 If the company have one user, then the name of the FE should be "CBAone.accde"
If the company have, for example four users the name of the FE:s should be "CBAOne.accde", "CBATwo.accde", "CBAThree.accde" and "CBAFour.accde"

7 I can create a folder U:\updates. This folder is hidden for all the users, but it is a common folder accessible from all logins. In U:\updates I will place the latest update of the FE.

8 When a user log on "something" check if he or she has the latest FE. If not the new FE from U: is copied to the users folder (\\BADC\NameOfCompany\data\) and given a file name, depending on the log in, for example "CBAthree.accde"

9 The new, latest FE must have its tables refreshed to the BE in the company folder \\BADC\NameOfCompany\data\

10 I can create a file with a table (Access or Excel) and place it the U:\updates. This table will have the following data:
CompanyName as text
UserName as text
PathOnServer as text

Is this a good idea for "roll outs" of updated FE:s?
Is it doable?

---

Cheers // Peter Forss Stockholm

Answer 6

Hmm... I would question some of this.

Of particular concern would be:

1. Does this mean the BE files are on a wide area network? If so performance wil be poor and there is a real risk of corruption whether the users are at their workstation or connecting to it remotely

5. Placing the FE in the same folder as the BE is not a good idea. Users should never has direct access to files on the server

6. Using different names for each copy of the FE is both unnecessary extra work and liable to error. 8. Similar point to that above

10. Company info should be stored in a settings table within the app rather than an external table. If more than one company is using the same BE then put that table in the FE.

In order to recover those values when relinking to the BE, my clients have a separate configuration database which has a backup of data stored in local FE tables. During relink that data is automatically restored.

Answer 7

Hi isladogs

1. "Does this mean the BE files are on a wide area network? "

NO the BE and the FE is on the Windows 2012 server. Users run it as a remote desktop.

5. "Placing the FE in the same folder as the BE is not a good idea. "
OK ... I had FE and BE in separete folders. The result was constantly messages like this "Your network was interupted, please restart."
With FE and BE in the same folder it works fine.

6. "Using different names for each copy of the FE is both unnecessary extra work and liable to error. 8. "
As I had to keep FE and BE in the same folder I had to give unique names to each users FE.

---

Cheers // Peter Forss Stockholm

Answer 8

I strongly advise against allowing anyone to remote into the server itself.

I think this would be a security risk even if it was just one person from one company.

With the setup you describe, there is what sounds like a major risk of data breaches. 

Why can't users remote into their own workstations with a copy of the FE on their own PC?

Answer 9

not my field really - one would think that a forum on shell / batch for automating file copy will have the best experience - possibly remote desktop server / terminal services managers...

one minor note on the dialog - in my scenario there is no check that the FE is 'new' - - the batch shell code (or whatever it is called...)simply copies in the released FE from the server (where I put it each time) to the user's desktop - -overwriting what is there.... much simpler... and this is during the overall PC boot so the transfer time is not noticeable.

works great never had a problem with this...

Answer 10

Hi msdn

Yes a good idea. No check if there is a new version. Always copy.

---

Cheers // Peter Forss Stockholm

Answer 11

Why can't users remote into their own workstations with a copy of the FE on their own PC?

Hi isladogs

A FE on their own PC and the BE on the server.

First I think it is a matter of performance, depending on the bandwidth.
Second the setup I am thinking of, allows customers with Mac to run as they via a web portal can run the MS Access application.

Maybe I describe the set up in a bad way. I'll ask my tech guy to describe it better.

---

Cheers // Peter Forss Stockholm

Answer 12

Hi 

I got this from tech:

If I try to describe this in my own words.
- Any user, running PC, Mac or Tablet with an internet connection and a browser can use the setup.
- First enter the URL in your browser.
You enter a "portal" where you are promted to sign in with a username and password.
- After that you enter the Pulse Secure area. Now you can start your Windows Standard Remote Desktop Client. You click and the enter the connection and your parts on the server. There is a H: (reserved and private for each user) and a P: ("public" the company part of the server, used for shared documents, Excel files etc. On P: there is also a hidden folder with the company unique BE)

I have found this solution working well. Since the application is running on the remote server everything working fast regardless of bandwidth. If we install printer drivers each user can print from the remote desktop to local printers.

---

Cheers // Peter Forss Stockholm

Answer 13

Sorry that diagram really doesn't help - partly as much of the text is far too small to read.

I am incredulous that any tech guy would be recommending users accessing files on the server.

Sorry to repeat myself but its a potential disaster waiting to happen.

Lets see what others have to say about this suggested setup

Answer 14

Hi

I might be asking for too much. But if this is the wish list, what would your proposed solution look like?


- The application is "cloud-based" via remote desktop.
- PC users as well as Mac users should be able to run the application.
- Several users must be able to work with the database at the same time
- Bandwidth should not be crucial.
- The connection between the user's PC or Mac and the "cloud" must go via a VPN tunnel.
- I am looking for an easy way to update each individual user's FE

---

Cheers // Peter Forss Stockholm

Answer 15

Hi Peter

I really can't give a definitive answer as I've not recently had to deal with users on Mac workstations or with VPNs.

My understanding (I may be wrong about this) is that the use of VPNs with Access can cause major performance issues such as dropped connections and potential corruption resulting from that. Perhaps that's why your IT team are suggesting remoting into the server, precisely to minimise the effects of a VPN. If so, that's a mistake in my opinion.

However, perhaps the Mac issue can be overcome by installing a dual Windows boot on the relevant workstations and installing Access on the Windows partition.

One recommendation would be to to purchase licenses for MS Terminal Server (or whatever its called now) or Citrix in order to allow users to remote in to their own workstations and host the FE files on each machine. Others may suggest the use of Azure but, once again, I have no experience of that either.

I look forward to hearing viewpoints of others with regard to your wish list

Answer 16

Yes, VPN is never a good idea with Access directly, but in this case it is simply too connect using RDP, so Access isn't being run over VPN.

Your best bet is simply to setup a simply VBScript that copies a master copy of your front-end from the server to a local folder and then launch it.  This ensures the user always had a clean and up to date version.

Be sure to copy it to a truly local folder as now many folders profile, ... Can actually be held on other servers and can drastically impact performance and even lead to corruption issues.

I'd setup the backend in a hidden folder with traverse permissions and then have another folder for holding the matter copy of the front-end.

---

Daniel Pineault, 2010-2019 Microsoft MVP
Professional Support: http://www.cardaconsultants.com
MS Access Tips and Code Samples: http://www.devhut.net

Answer 17

Your best bet is simply to setup a simply VBScript that copies a master copy of your front-end from the server to a local folder and then launch it.  This ensures the user always had a clean and up to date version.

Be sure to copy it to a truly local folder

Hi Daniel

Thank you for helping. I have already the Table Database in a hidden folder. I, or my tech guy just made another folder where we can put the FE. (P:\Updates)

So we will try to edit a VBScript that copies from P:\Updates to the Users local folder. But since this application is used by four different companies, there are also four unique BE databases (tradingbase.accdb). What I do not understand is how to get each individual user's application to link its tables to the right company's tradingbase.accdb. How can this be automated?

\\BADC\Company1\data\\
\\BADC\Company2\data\
\\BADC\Company3\data\
\\BADC\Company4\data\

---

Cheers // Peter Forss Stockholm

Answer 18

Actually in this context?

Why would users not use files from a server? That ***IS*** their purpose in life.

You have some word documents or PDF documents or even a access data file? You place them on a server and that way everyone can use those files.

So yes, placing files on a server and letting people use those files is quite much the WHOLE idea of a server.

So no, I don't see the problem here. You might have to expand on the context here, but the general approach of having some files on some server in some folder is the whole idea and quite much the WHOLE basis of our industry from day one when we started adopting networks. 

Regards,

Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Answer 19

Ok, is the back end for each data file in the same folder?

What is causing a good amount of confusing here is I think some missed that each user has their own copy of FE and BE. The data in the BE is NOT shared by multiple users. If THIS IS the case, then we have:

Many users (on the remote server).

Several FE's. Each user gets their OWN copy. Place these in MyDocuments or some "per user" based folder.

If the several FE's are to link to a BE in the SAME user folder?

Well then on application startup, you simply need to have some re-link code. It will simply check in a linked table is pointing to the correct (same folder) BE. If not, then a one-time re-linking of the tables will be required. 

If the BE for all 4 FE's is to be the SAME for all remote users, then of course you can pre-link to the BE's, since they are fixed and NOT deployed per user. However, if the BE's are separate for each user and each FE? Then this would suggest that both FE + BE are deployed to the "per user" folder. In that case, as noted, you need some VBA code to re-link the tables (one time) on startup.

So if you have say several users, and they all need to edit the same data (BE)?

Well, then as noted, each user STILL gets their own FE in some "per user" folder, but the BE can be in a static fixed back end folder. If the BE is per user, then obviously you are going to copy both FE + BE to that "per user" folder, and then you have the re-link check in VBA.

So if the BE's are to be the same for all 4 FE's (even with multiple users), then the BE's don't go in a per user folder, but the FE's will and do. In this case, since the BE's are not changing or "per user", then you can deploy pre-linked to the BE's.

So the above should cover how this works. The rule of EACH user STILL having their OWN FE remains in effect, even in this case of a remote desktop server (as is your case). 

So with, or without terminal services, the rule of each user having their own FE's remains. The sharing of BE's among those users (if desired) is of course standard fair.

So it looks to be that each FE/BE combo is 100% separate. If that is the case, then of course a deployment/copy/update for new FE's will thus re-quire a re-link on startup. The reason of course is that linked tables cannot use a "relative" or "current folder" link - it has to be a full static path name. So, a re-link will be required. The re-link code of course can easy pull the current FE path/location, and use that information to re-link to the BE that is assumed to be in the same folder.

The above should quite much thus cover your basis. The only question (which was your simple original question) is then how to update, as a manual process can be a lot of work.

As noted, there are as many ways as ice cream flavors to do this. A little batch file or even a script file can work. Another way? I have in startup a small FE table with a version number. And then on the BE, I also have a small table with version number. So, I check the two values. If FE is less (behind) then you can have the FE copy a new FE from a known/static locaiton (shared folder with the FE's). Now of course once that FE figures out it need to be updated, then you can't copy the new server folder FE "over itself". So you can shell() out to say a batch file, or even another tiny MyUpgrader.accDE program. it thus copies the FE (that we now exited out of), and then you are free to overwrite (copy from server) the new FE. So, you can use a batch file, vbsscript or quite a few approaches (I used a 2nd FE called MyUpgrader).  

However major "key" to making this all work is that assuming the BE's are "per user" then you will have to re-link on application startup to the current "per user" folder where the BE also resides.

Regards,

Albert D. Kallal (Access MVP 2003-2017)

Edmonton, Alberta Canada

Answer 20

Albert

"What is causing a good amount of confusing here is I think some missed that each user has their own copy of FE and BE. The data in the BE is NOT shared by multiple users. If THIS IS the case, then we have:..."

That isn't the case here. Each COMPANY has its own BE but there are several users in each company each with their own copy of the FE which they run from the same server folder. I'm not clear whether there is anything to prevent users opening 'someone else's' copy of the FE or indeed to stop multiple users opening the same copy at once

Answer 21

100% agree.

As noted, my post/narrative covers this issue. For better or worse, we can't link to ta BE with relative path names - has to be full path name.

So, the simple solution will thus require some code on startup to check a table link, and if it not pointing to current folder then you have to re-link. This will of course only occur one time.

So, all in all - yes, I believe I grasped your narrative, and I well covered both cases. (several FE's pointing to a common BE, and that of FE's always pointing to a local, single use BE).

So, two challenges:

how to update. As noted, many great ideas. - even a simple batch file placed in the same folder could be used and you shell() from Access (and exit to allow the overwrite copy process). However, no matter what of many approaches used to update the FE's, for this to be practical, you need/want/have/adopt some kind of test and optional re-link on startup to link up the FE/BE set.

Regards,

Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Answer 22

Hi

Here is a description of the situation and the goal.

The User first login to the Pulse Secure SSL-VPN Security product and then connect to the RDS server via a Terminal Session link.

Depending on username and password the user comes to to to his own company's Virtual Machine on the server. Each user gets access to a private folder structure (H: \), plus the company-wide (P: \).

In P: \data\ there is a common BE database for everyone, within the specific company.

The UNC to the private H: and the FE could be written like this for two users - \\BATS\Users$\NNN.One\CBA.accde and \\BATS\Users$\NNN.Two\CBA.accde

The UNC to the corporate P: is written like this \\BADC\NNN\data\trading base.accdb

In another company, these become the respective UNCs:

\\BATS\Users$\MMM.One\CBA.accde, \\BATS\Users$\MMM.One\CBA.accde and

\\BADC\MMM\data\trading base.accdb

I can have a the latest updated FE CBA.accde in a hidden folder, accessible to all company logins. This FE can be copied down to each user's H :. But how do you get the table links to each company's BE right?

In company NNN the path to the BE is \\BADC\NNN\data\trading base.accdb.

In company MMM the path is \\BADC\MMM\data\trading base.accdb.

Is it possible to write some code that handles this?

---

Cheers // Peter Forss Stockholm

Answer 23

Ok, and yes, i think you can.

The only real Rosetta stone information you need for the FE re-link process is that company information. This could be even a .txt file or some such that you ALSO copy into each folder. And thus your FE re-link code can then include the "MMM" or whatever as part of the re-link process on startup. (it would open/read the company.txt file on startup).

So while I covered both cases, it does look like you could/would have say several users each with their own FE's, but they would in fact be linked to  a common BE if they are supposed to part of a given company group. So, this suggests that you need the company group info when doing a table link to point to the correct and common BE that is to be shared for a given company group. So, you quite much need in addition to the copy of the FE's to that folder for each user (and broken further down by company group), to include some simple txt file that includes the correct path name to the given company group BE's to be used.

so the re-link code (there are quite a few examples floating around), would grab/get a linked table, look at the link path, and if it does not match the value in the text file (to be included in the same folder as the FE's), and then re-link. If they match, then no re-link would be required.

So, my bets are to include a text file in the FE's that you copy during the first setup, and that text file would point to the correct BE. You then check and re-link on application startup based on the value in that text file.  VBA code in application startup can pick up the current folder where the FE is running, and then read a known text file (assumed to be in the same folder as the FE) to get the correct BE to link to. 

Regards,

Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Answer 24

You may wish to study my article:

Deploy and update a Microsoft Access application with one click

It differs for item 8 by always copying a fresh copy of the frontend.

---

Gustav Brock

Answer 25

Hi

This is VBA code working. I takes the path to the BE from a txt file.
But it is working within the Access app.

But I will definitly look into Gustavs code. If I am right Gustavs code do the whole thing.

Function Refresh_Links()

    On Error GoTo Refresh_Links_Error

Dim strFilename As String: strFilename = "C:\databaser\yourfile.txt"
Dim strFileContent As String
Dim iFile As Integer: iFile = FreeFile
    
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
Dim fso As New FileSystemObject
Dim fileName As String
Dim dbPath As String

Open strFilename For Input As #iFile
strFileContent = Input(LOF(iFile), iFile)
Close #iFile

dbPath = strFileContent
fileName = "trading base.accdb"

For Each tdf In db.TableDefs

    If tdf.Connect Like ";DATABASE*" Then
    
        fileName = fso.GetFileName(tdf.Connect)
        tdf.Connect = ";DATABASE=" & dbPath & "\" & fileName
        tdf.RefreshLink
            
    End If
    
Next tdf
    
    On Error GoTo 0
    Exit Sub

Refresh_Links_Error:

    MsgBox "Error " & Err.Number & " (" & Err.description & ") in procedure change_Links, line " & Erl & "."

End Function

---

Cheers // Peter Forss Stockholm

Answer 26

You may wish to study my article:

Deploy and update a Microsoft Access application with one click

It differs for item 8 by always copying a fresh copy of the frontend.

---

Gustav Brock

Gustav

Although that's not the approach I use, I have bookmarked your excellent article to recommend to others in the future

Answer 27

Hi Gustav

Your scripts does not refresh the linked tables, does it?

But I think if I combine your solution with my Function Refresh_Links and in AutoExec macro have a line RunCode Refresh_Links(). The I have the wanted solution.
(I place a txt file in the same folder as the download FE)

Function Refresh_Links()

    On Error GoTo Refresh_Links_Error
    
Dim strPath As String
strPath = CurrentProject.Path

Dim strFilename As String: strFilename = strPath & "\" & "yourfile.txt"
Dim strFileContent As String
Dim iFile As Integer: iFile = FreeFile
    
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
Dim fso As New FileSystemObject
Dim fileName As String
Dim dbPath As String

Open strFilename For Input As #iFile
strFileContent = Input(LOF(iFile), iFile)
Close #iFile

dbPath = strFileContent
fileName = "trading base.accdb"

For Each tdf In db.TableDefs

    If tdf.Connect Like ";DATABASE*" Then
    
        fileName = fso.GetFileName(tdf.Connect)
        tdf.Connect = ";DATABASE=" & dbPath & "\" & fileName
        tdf.RefreshLink
            
    End If
    
Next tdf
    
    On Error GoTo 0
    Exit Function

Refresh_Links_Error:

    MsgBox "Error " & Err.Number & " (" & Err.description & ") in procedure change_Links, line " & Erl & "."

End Function

---

Cheers // Peter Forss Stockholm

Answer 28

> Your scripts does not refresh the linked tables, does it?

No, and you should not do it regularly as it can take a long time, indeed for ODBC connected tables.

It is only necessary to refresh the links if the backend has been moved, or tables have been added or modified.

---

Gustav Brock

Answer 29

Hi Gustav

Just did a test.

Relinking tables give a total start up time of 27 sec.
Without relinking it takes 5,5 sec.

---

Cheers // Peter Forss Stockholm

Answer 30

Hi 

Is it possible to code something like this. (refers to my Function Refresh_Links ())

If First tables link = link string in txt-file "yourfile.txt" then
stop to refresh all links.
else
Continue to refresh all links as in txt-file "yourfile.txt
end if

---

Cheers // Peter Forss Stockholm

Answer 31

Here is query that returns a FE file current BE connection:

SELECT DISTINCT MSysObjects.Database
FROM MSysObjects
GROUP BY MSysObjects.Database, MSysObjects.ParentId, MSysObjects.Name, MSysObjects.Type
HAVING (((MSysObjects.Name) Not Like "*TMP*") AND ((MSysObjects.Type)=6));

Perhaps you can save it as a query something like ActiveBEConnection and use that as your criteria.

So If DLookup("[Database]","ActiveBEConnection")= "Your Customers BE File Path" Then

Do Nothing

Else

Relink

End If

Answer 32

Hi Lawrence

Just to point out that your query will pick up Access/Excel/CSV connections but not those in ODBC connections such as SQL Server which have a Type value = 4.

Grouping ParentID is superfluous in this query.

Also, it isn't actually showing the connection strings which are stored in the Connect field.

IMO this would be better as well as faster (WHERE vs HAVING):

SELECT DISTINCT MSysObjects.Connect, MSysObjects.Database
FROM MSysObjects
WHERE (((MSysObjects.Name) Not Like "*TMP*") AND ((MSysObjects.Type)=4 Or (MSysObjects.Type)=6))
GROUP BY MSysObjects.Connect, MSysObjects.Database;

Answer 33

Is it possible to code something like this. (refers to my Function Refresh_Links ())

Hi Peter,

In my applications I have a one-record-table that describes a number of general features of the application. 

For instance what is the first userform to start with, what is the basic color of the application (all other colors used are shades of this basic color), but also what is the path that is last used to connect the BE.

Only if the "Connected_to" path is different from the current path of the BE, a relink is automatically done, and the new path is stored in the "Connected_to" field.

Imb.

Answer 34

Hi Lawrence and isladogs

And thank you.

I modified my code and now time to open  is the same, if the links to table = path in the txt file

Dim strPath As String
strPath = CurrentProject.Path

Dim strFilename As String: strFilename = strPath & "\" & "BEpath.txt"
Dim strFileContent As String
Dim iFile As Integer: iFile = FreeFile
    
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
Dim fso As New FileSystemObject
Dim fileName As String
Dim dbPath As String

Open strFilename For Input As #iFile
strFileContent = Input(LOF(iFile), iFile)
Close #iFile

dbPath = strFileContent
'Name of the BE
fileName = "trading base.accdb"

If DLookup("[Database]", "ActiveBEConnection") = strFileContent & fileName Then
Exit Function
Else

        For Each tdf In db.TableDefs

            If tdf.Connect Like ";DATABASE*" Then
    
            fileName = fso.GetFileName(tdf.Connect)
            tdf.Connect = ";DATABASE=" & dbPath & "\" & fileName
            tdf.RefreshLink
            
            End If
    
Next tdf
End If

---

Cheers // Peter Forss Stockholm