Very Weird Problem (1 Viewer)

[Emma35]

Hi All,
I have a form in a database which has been working without any issues for several years. The form contains a text box and a list box which i use to perform a keyword search. When i type into the textbox, a set of results appear in the list box and i can then double click on the one i need, which opens another form containing information i need. As of last Monday, when you double click on a result from the list box you get the error below. Everybody else who works with me are getting this error but my PC is fine and the database is working fine.
I have Googled this to death and cannot find a solution which works. Why is it happening on one PC and not on another ?? The database is stored on a shared drive and the various users are all using a link which i've checked and is pointing to the right file. Here are some of the things i've tried

Compact & Repair
Debug ---- Compile Test
Restored old file from 1 month ago
Checked the references
Created new database and imported everything

Has anyone ever seen something like this before ?

Thanks guys

 

[theDBguy]

I've seen this happened with reports but not forms, although I imagine it's possible. If nothing was changed in the application, then I would look into the data. Otherwise, maybe the form got corrupted somehow.

 

[mike60smart]

Hi All,
I have a form in a database which has been working without any issues for several years. The form contains a text box and a list box which i use to perform a keyword search. When i type into the textbox, a set of results appear in the list box and i can then double click on the one i need, which opens another form containing information i need. As of last Monday, when you double click on a result from the list box you get the error below. Everybody else who works with me are getting this error but my PC is fine and the database is working fine.
I have Googled this to death and cannot find a solution which works. Why is it happening on one PC and not on another ?? The database is stored on a shared drive and the various users are all using a link which i've checked and is pointing to the right file. Here are some of the things i've tried

Compact & Repair
Debug ---- Compile Test
Restored old file from 1 month ago
Checked the references
Created new database and imported everything

Has anyone ever seen something like this before ?

Thanks guys

View attachment 111341

Which shared Drive are you using?

 

[Isaac]

Hit debug and start troubleshooting

 

[CJ_London]

The database is stored on a shared drive and the various users are all using a link which i've checked and is pointing to the right file

that sounds suspicious to me - each user should have there own copy of the front end stored locally on their machine and linked to the back end on the shared drive. Your description implies they are all using the same front end on the shared drive. If this is the case, you have been lucky in that you have not corrupted the front end so far - but that may now be happening. Users should never share the same front end file.

 

[Isaac]

Definitely doing it the wrong way - split the database everyone gets their own FE, all pointed toward linked tables in one shared BE

 

[Pat Hartman]

The message is telling you the exact problem. Whatever code you ran to open some other form or report did not complete because the form or report did not open, probably due to some error. A typical situation is opening a report that has no data selected.

To resolve the issue, you need to add error trapping to the procedure that calls whatever is not opening. Trap the 2501 error and either ignore it or provide your own, more meaningful error message.

 

[Emma35]

Ok thanks all for the recommendations. I'm back in work on Sunday and i'll try a few things.
* There are about 50 users approx so do i have to put a copy of the FE on each machine ?
* Pat.....how do i trap the 2501 error ?. Even i i change it to a more user friendly message the issue will still remain ? I have checked the form that won't open and it looks fine. It opens perfectly on my machine but not the others

 

[mike60smart]

Ok thanks all for the recommendations. I'm back in work on Sunday and i'll try a few things.
* There are about 50 users approx so do i have to put a copy of the FE on each machine ?
* Pat.....how do i trap the 2501 error ?. Even i i change it to a more user friendly message the issue will still remain ? I have checked the form that won't open and it looks fine. It opens perfectly on my machine but not the others

Hi Emma

You need to carry out the following Process to split your database.

Also the following explains how you Sharing share the database on your network

 

[Isaac]

Hi Emma

You need to carry out the following Process to split your database.

Also the following explains how you Sharing share the database on your network

And you'll need a version updating method, https://www.access-programmers.co.u...-desktop-database-to-web.310800/#post-1757974

nowadays most often I create a vbscript that copies the network FE to the user's local temp folder every time they open it (your FE's should typically be pretty small if they're done right), or at least every time there's a new version, then opens it. create a shortcut file to the vbs file, brand the shortcut with some nice logo, tell them to copy the shortcut to their desktop and you're done - a lifetime of free updating and you don't need to pay anyone from their special website with their special tool - very simple to do yourself

 

[Pat Hartman]

Here is the simplest batch file you can make.

md c:\DwgLog
del c:\DwgLog\DrawingLog.accdr
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdr" c:\DwgLog
c:\DwgLog\DrawingLog.accdr

1. make a directory on the C: drive. Make the name short but relevant. Mine is DwgLog -- no error will be raised if the folder already exists so you don't need separate batch files for new and existing users.
2. delete any existing copy of the FE from this folder. My fe is named DrawingLog.accdr -- no error will be raised if there is no file to delete
3. copy the master DrawingLog.accdr from the server to the local folder. Always use the UNC path for the server rather than a mapped drive letter. -- If something happened to the master copy, this will raise an error.
4. Open the application. -- If there is something wrong with the FE, this will raise an error.

You can add error trapping for 3 and 4 if you think it is necessary.

The batch file and the master copy of the FE live in a folder on the server. You can create a shortcut that opens the batch file. In my case, the batch file name is DwgLog.bat You could use VBScript if you prefer. Then email the shortcut to all the users with instructions to save it to their desktop.

That's it. Now, whenever you need to distribute a new copy of the FE, you replace the master copy on the server. Make sure it is linked to the production copy of the BE -- remember, when you are testing, your test copy of the FE MUST be linked to a test copy of the BE because you don't want to break production data. So, the last step before distribution is relinking. The user must never do this. YOU need to do it.

If you have existing FE's out in the wild that someone might accidentally use, the best option is to rename the BE so they will break. Now only the version opened by the batch file will work going forward.

Here is a simple sample of an error trap that ignores error 2501 but displays a message for any other error code.

Private Sub cmdViewRpt_Click()
   On Error GoTo Err_Proc

    DoCmd.OpenReport "rptClientList", acViewPreview

Exit_Proc:
   On Error GoTo 0
   Exit Sub

Err_Proc:

    Select Case Err.Number
        Case 2501       'report cancelled
            Resume Next
        Case Else
            MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure cmdViewRpt_Click of VBA Document Form_frmSearchResults"
    End Select
End Sub

 

[Gasman]

@Pat Hartman
No need to delete the file surely, it will be overwritten?

 

[Isaac]

Here is the simplest batch file you can make.

md c:\DwgLog
del c:\DwgLog\DrawingLog.accdr
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdr" c:\DwgLog
c:\DwgLog\DrawingLog.accdr

1. make a directory on the C: drive. Make the name short but relevant. Mine is DwgLog -- no error will be raised if the folder already exists so you don't need separate batch files for new and existing users.
2. delete any existing copy of the FE from this folder. My fe is named DrawingLog.accdr -- no error will be raised if there is no file to delete
3. copy the master DrawingLog.accdr from the server to the local folder. Always use the UNC path for the server rather than a mapped drive letter. -- If something happened to the master copy, this will raise an error.
4. Open the application. -- If there is something wrong with the FE, this will raise an error.

You can add error trapping for 3 and 4 if you think it is necessary.

The batch file and the master copy of the FE live in a folder on the server. You can create a shortcut that opens the batch file. In my case, the batch file name is DwgLog.bat You could use VBScript if you prefer. Then email the shortcut to all the users with instructions to save it to their desktop.

That's it. Now, whenever you need to distribute a new copy of the FE, you replace the master copy on the server. Make sure it is linked to the production copy of the BE -- remember, when you are testing, your test copy of the FE MUST be linked to a test copy of the BE because you don't want to break production data. So, the last step before distribution is relinking. The user must never do this. YOU need to do it.

If you have existing FE's out in the wild that someone might accidentally use, the best option is to rename the BE so they will break. Now only the version opened by the batch file will work going forward.

Here is a simple sample of an error trap that ignores error 2501 but displays a message for any other error code.

Private Sub cmdViewRpt_Click()
   On Error GoTo Err_Proc

    DoCmd.OpenReport "rptClientList", acViewPreview

Exit_Proc:
   On Error GoTo 0
   Exit Sub

Err_Proc:

    Select Case Err.Number
        Case 2501       'report cancelled
            Resume Next
        Case Else
            MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure cmdViewRpt_Click of VBA Document Form_frmSearchResults"
    End Select
End Sub

I usually use the temp or appdata folder because in modern corporate life most people don't have access to their c drive

 

[Gasman]

I usually use the temp or half day to folder because in modern corporate life most people don't have access to their c drive

Half day?
Auto correct on phone?

 

[Pat Hartman]

I usually use the temp or half day to folder because in modern corporate life most people don't have access to their c drive

If that's the case, they're probably running under Citrix and that is a different batch file

 

[Pat Hartman]

No need to delete the file surely, it will be overwritten?

It only gets overwritten if the download succeeds. Best to have it gone.

 

[Isaac]

Half day?
Auto correct on phone?

Appdata

 

[Isaac]

If that's the case, they're probably running under Citrix and that is a different batch file

In no corporation that I've worked in the past 6 to 8 years have I had any access to my c drive especially if the laptop belongs to the company

 

[Isaac]

Appdata

Yeah I always use app data or the temp folder, app data still works well under most corporate user permission structures

 

[Emma35]

Hi All....just trying a few things here. The database was actually split into a FE and BE but i admit i didn't have a copy of the FE on each User's PC. will be back to you shortly