Solved Database only works in the computer where it was created (1 Viewer)

[Cris VS]

Hello everyone,

I designed a database with plenty of forms and reports and when it was finished, I decided to split it. At first I did all of this in my computer but then I decided to move both the backend file (that contains only tables) and the frontend to a shared folder in the network. I re-linked my tables to match the new location and in my computer it worked fine.

When I tested it on another computer, various things that I had programmed didn't work, for example, the custom shortcut menus or the button to Export a group of queries to Excel. I have no clue of how or where to start looking for the bugs that are making my application not work properly in this other computer.

Could you help me?

Many thanks

PS: The shortcut menus are programmed on the "On Open" event of the menu form that is used as Display form for the current database. This is the error message that appears:

PS2: As I put a lot of VBA into the frontend file and it looks like it is only the VBA parts that don't work, I checked that the file opened in the other computer had all the references set properly and it was OK, so I don't know what else to look for.

 

[CJ_London]

regret the image is too fuzzy to make out.. All I can read is the header 'software validation' and what looks like 'could not find the object????'

You should not put the frontend in a shared location, each user should have a copy on their local drive. This may solve your problem. But I suspect the error message is telling what is missing - perhaps a file that needs to be on each computer? Have you clicked on the help? button to see what information it gives you?

The other thing to be aware of is the front end should be located in a trusted location

 

[Cris VS]

regret the image is too fuzzy to make out.. All I can read is the header 'software validation' and what looks like 'could not find the object????'

You should not put the frontend in a shared location, each user should have a copy on their local drive. This may solve your problem. But I suspect the error message is telling what is missing - perhaps a file that needs to be on each computer? Have you clicked on the help? button to see what information it gives you?

The other thing to be aware of is the front end should be located in a trusted location

Sorry about that, it says:
'App_Name' cannot find the object 'MenuName.'
If 'MenuName' is a new macro or macro group, make sure you have saved it and that you have typed its name correctly.

I will try checking that.

Maybe my question is dumb but this is my first proper Access app... if it works fine opening from the shared location in one computer, shouldn't it also work in another?

 

[CJ_London]

the problem with sharing a FE is that as soon as you open it, changes are made to the file, As you use the app more changes can occur. So if more than one user has the same FE open at the same time, those changes can clash and cause the file to become corrupted. May not happen today or tomorrow, but it will happen. Try it - open the file, do nothing then close the file - you'll see the date modified has changed.

Other issues include network outages which will leave the file in an uncertain state (so you should not be using wireless which is more prone to outages).

Performance will also be compromised as Access has to not just bring data across the network, but everything to do with the front end as well

 

[Cris VS]

Hi again,

I have tried saving the file in a different computer in folder C:/Temp but it is still giving the same error: it can't find the objects that I defined in VBA in different forms/reports... the references are set just as they appeared in my computer so I don't know what to do... These are the screenshots of the extended error message:

 

[arnelgp]

post a sample db. you post pictures, where can we look for that error?

 

[Cris VS]

Unfortunately I cannot post my database but I am posting a super simple one... I hope it is enough. The code on the "On open" event is exactly the same. The error message pops up when trying to use the right-click.

Thanks

 

[arnelgp]

what version of msa are you using.

i have a2019.
you put your code in separate module.
call it in autoexec macro.

 

[Cris VS]

MSA2016

you put your code in separate module.
call it in autoexec macro.

Could you explain this a bit more detailed? Do you mean like this?

How do I call this afterwards from my form? I am thinking of a code that in fact you helped me with it in this question about VBA. In this case, there is a button in a form that executes the code to export to excel and it is also giving me problems when opening from other computers, so how can I do it? also as a module?

Thanks

 

[arnelgp]

see my sample on how i did it.

 

[moke123]

Your sample appears to work fine. No error on right click.
You didn't set the shortcut menu bars in the properties of the textboxes.

 

[The_Doc_Man]

Maybe my question is dumb but this is my first proper Access app... if it works fine opening from the shared location in one computer, shouldn't it also work in another?

I'm going to answer this narrow question.

The answer is a resounding "maybe not." Each computer has one thing that is potentially different from other computers - its installed software configuration. Factors that can affect software compatibility include:

1. Which version of Windows (including the "build number") that each computer is running.
2. Which version of Office is installed?
3. Which bitness (32- or 64-bit) of Windows was installed?
4. Which bitness (32- or 64-bit) Office was installed? (If 32-bit Windows, you can ONLY have 32-bit Office; with 64-bit Windows, either bitness is OK for Office.)
5. Which references are selected in the VBA window >> Tools >> References list, which is retained in the registry, which is unique to the machine?
6. Then.... what are the effective file permissions on the front end and back end files with respect to each user?
7. For the machine that is failing, is the version and bitness of Office the same as the one on which the app was developed?

ALL of the above contribute to defining how the code will work on each computer. And I'm sure my colleagues could add a few to the list.

 

[Cris VS]

I'm going to answer this narrow question.

The answer is a resounding "maybe not." Each computer has one thing that is potentially different from other computers - its installed software configuration. Factors that can affect software compatibility include:

1. Which version of Windows (including the "build number") that each computer is running.
2. Which version of Office is installed?
3. Which bitness (32- or 64-bit) of Windows was installed?
4. Which bitness (32- or 64-bit) Office was installed? (If 32-bit Windows, you can ONLY have 32-bit Office; with 64-bit Windows, either bitness is OK for Office.)
5. Which references are selected in the VBA window >> Tools >> References list, which is retained in the registry, which is unique to the machine?
6. Then.... what are the effective file permissions on the front end and back end files with respect to each user?
7. For the machine that is failing, is the version and bitness of Office the same as the one on which the app was developed?

ALL of the above contribute to defining how the code will work on each computer. And I'm sure my colleagues could add a few to the list.

So if all of this were equal in both computers, the "VBA parts" of the file should run normally?

 

[gemma-the-husky]

Are all your computers running an accdb or an accde

if an accde (compiled) then you won't be able to work out what's going in. If an accdb, then you need to debug the app on the second computer to work out what the problem is. I would do this in a "test" mode with no other users in the database

Similar to what @The_Doc_Man said.
Check the code references to make sure there are none missing. Missing references cause all sorts of strange incorrect errors of the sort you are seeing. Secondly make sure the code compiles. Make sure all the Access versions are of the same bitness. The version number might matter, but if you use the wrong version, you will get a clean "wrong version" message rather than the errors you are seeing.

If the database does start normally, then set a breakpoint at the first line that runs. If it fails before anything runs, I would add an autoexec macro to give a startup fiunction, rather than setting a startup form. (or temporarily have no startup form, so you can choose the form yourself). Then put a breakpoint in the _open event for that form.

This is all good - you will learn and understand a lot from resolving this problem.

Access is generally forgiving, and will sort out differences itself but it will cause issues if you try to run it on the wrong Access. If multiple people are opening the SAME copy of the database with different Access bitness versions, you will almost certainly get strange behaviour.

 

[Cris VS]

Hello all, it was finally due to an issue with the trusted files of the network... It was just a matter of permits. Thank you for all the tips, they have helped to arrive to a solution

 

[gemma-the-husky]

Glad you got it sorted. That's one more thing that you will immediately remember in the event of a similar problem in the future.

 

[The_Doc_Man]

Hello all, it was finally due to an issue with the trusted files of the network... It was just a matter of permits. Thank you for all the tips, they have helped to arrive to a solution

Ah, yes... Trust Center issues, which fall under my #6 item. Glad you found it.

 

[arnelgp]

my #6 item

it's about file permission on FE/BE, remember?

 

[CJ_London]

Actually I mentioned it in post #2 (not trying to be competitive!)

 

[The_Doc_Man]

Arnelgp, the trust center IS about permissions.

CJ, you did indeed. I was merely enumerating causes for differences in behavior but you certainly suggested a trust center issue.