Solved RefreshLink Code Takes Forever to Complete in Runtime (2 Viewers)

[Pac-Man]

Hello,

Hope you are all in good health. I am facing an unexpected issue. FE of my application is being used two locations where both locations have different encryption password for their Access BE database. I'm using following code to update password in the FE when rhe file load. First it checks if BE password is already changed or not and if it needs to be updated, it loops through all the tables and replace the old password with new one.

The code works perfectly in Access and I can password with no problem, but when I open the FE in access runtime and try run the code, it took forever to complete. To get the location of code where it stuck, I put code to log completion of every action in the code in a text file and I found that it never get passed 140 .RefreshLink line of the first table whose password needs to be updated.

The code has error handler and no error displayed, just code take forever to complete. What could be the reason and to get past this.

Best Regards

70            For Each tdf In db.TableDefs
80                With tdf
90                    If (.Attributes And dbAttachedTable) = dbAttachedTable Then
                          'it is a linked table
100                       tbl = .Name
110                       If Not (tbl Like "~*") Then
130                           .Connect = Replace(.Connect, "PWD=" & sOldPwd, "PWD=" & sNewPwd)
140                           .RefreshLink
150                       End If
160                   End If
170               End With
180           Next tdf
190       End If

 

[theDBguy]

I'm not sure why the code is hanging in runtime, but you might try recreating the linked tables instead of just refreshing them.

 

[June7]

By "access runtime" you mean clients do not have full Access program, just Runtime? Are they running an accdb frontend?

You say it "works perfectly in access" - so you mean on your PC with full Access program? Are you actually changing password in this case?

 

[CJ_London]

Is the BE in the exact same location?

 

[Pac-Man]

By "access runtime" you mean clients do not have full Access program, just Runtime? Are they running an accdb frontend?

You say it "works perfectly in access" - so you mean on your PC with full Access program? Are you actually changing password in this case?

Thanks all for the reply. Yes Clients do not have full access. I tried on my pc with full Access and it worked flawlessly and then I installed runtime and it had shown the issue. I also replicate the same behaviour on other pc having full Access and it work flawlessly while not in runtime on the same pc. Passwords are changed automatically through this code when old password is not the same as new password. It is the case the FE goes to two users I mentioned.

Is the BE in the exact same location?

Yes BE is exact same location. Just passwords are different, no other change.

'm not sure why the code is hanging in runtime, but you might try recreating the linked tables instead of just refreshing them.

By recreating, you mean at design time or recreate in runtime?

 

[theDBguy]

By recreating, you mean at design time or recreate in runtime?

By it I mean you can delete the existing linked tables and then create them again using the new password.

 

[Gasman]

If you name your FE as an accdr, does it happen then?

 

[Pac-Man]

I recreated the whole db from source code using version control and this problem seem to have resolved for now.

If you name your FE as an accdr, does it happen then?

Sorry I missed to mentioned that my FE is accde. Didn't check with accdr.

 

[Pat Hartman]

Gasman meant renaming the .accde to .accdr and trying that on YOUR PC to see if it had the same effect as actually using the Runtime engine on the user PC. The .accdr extension is supposed to tell full version Access to pretend to be the Runtime.

 

[Pac-Man]

Gasman meant renaming the .accde to .accdr and trying that on YOUR PC to see if it had the same effect as actually using the Runtime engine on the user PC. The .accdr extension is supposed to tell full version Access to pretend to be the Runtime.

I didn't check by renaming the .accde to .accdr but I used /runtime switch to check on my computer and it had showed the issue and that is how I come to know about the problematic location of the code. I cannot reproduce it as the issue seem to be resolved by rebuilding the database (perhaps @theDBguy 's suggestion of deleting and then recreating tables was the fix).