Forms don't show in Split DB FE

[Zydeceltico]

All -

I have a db that I have split into back end and front end. The front end opens to a form that acts like a switchboard - but I did not use the switchboard function to create it. I simply created a blank form that I added buttons to to open other forms and run pre-created queries.

The backend is on a shared, public network drive. The original front end is on my desktop.

I sent a copy of the front end to my co-worker with zero restrictions placed on it. I wouldn't even know how to put restrictions on it.

So when I open the front end on my desktop, everything works exactly as expected. All forms open and operate.

My co-worker's front end does not operate as expected.

His copy opens to the "main menu" form that I created. When he clicks a button that launches a query, that operates perfectly.

OTH, when he clicks any button that is intended to open a data entry form, nothing happens. No form opens and there is no error message.

There is ONE exception. One of the buttons open a form that I just created last week (all the others are months old). For some weird reason the button recently created to open a form that was created last week does in fact open the intended form (which functions as expected).

I created this new for exactly the same way I created all of the other forms and I placed the open form button on the main menu in exactly the same manner as all of the rest of the open form buttons.

Ideas?

Thanks in advance,

Tim

 

[isladogs]

Just to confirm. Are the forms in the FE as they should be?
Has the other user saved the FE to a trusted location or clicked Enable Content?
Have they relinked the tables? This will need to be done if the location isn't the same

 

[Zydeceltico]

Just to confirm. Are the forms in the FE as they should be?
Has the other user saved the FE to a trusted location or clicked Enable Content?
Have they relinked the tables? This will need to be done if the location isn't the same

The forms are in the FE.

Enable Content has been clicked.

The tables have not been relinked. I didn't know I needed to do that. Makes sense though. What I don't understand is how that new form functions when the other's don't.

How do I "relink" tables?

Thanks,

Tim

 

[The_Doc_Man]

OK, let's split the concerns.

I did not use the switchboard function to create it. I simply created a blank form

Not an issue. I've done that myself. No problem. There is nothing "magic" about a switchboard. It looks special only because Access has a template for it. It just has to be selected as the default opening form on FE launch.

OTH, when he clicks any button that is intended to open a data entry form, nothing happens. No form opens and there is no error message.

If this has never worked, the answer is one thing. If this stopped working, the answer is something else. The fact that a recently created form works says that the switchboard is capable of opening forms, so that capability is not broken. (So that means that we must look elsewhere.)

Two possibilities come to mind, both involving the button-click code behind the launcher buttons you created.

Sub-case A: Have you recently renamed the button controls since they were first built? Because the event name and event entry point are intimately related, if you have renamed buttons, you must rename and re-establish the event entry points. There is a variant of this that if you did a global replace of something AND that something could have been part of the button name, it would inadvertanly be part of the event name, too. So if you changed the event name rather than the button name, your problem would still be that you have a mismatch between the button-click event name and its corresponding button name. Doesn't matter which side is broken.

This might be so simple as to get the correct spelling of the command button name, find the correct event code routine under the old name, rename the entry point, and go back and re-establish that you want to use event code. It will start to create a new event but then will detect that code already exists for that event and will just establish the new link - silently. You could also get into the VBA editor and look for all "_Click" strings (with "match whole words" NOT checked) to verify the event names match the buttons.

Sub-case B: Something has gone wrong in the event code or the whole form. If you have error handling enabled in the event routine, make it do something very visible - like pop up a message box to tell you that somehow you have screwed the pooch by breaking something.

If you have error messages disabled, enable them now so you can find the error.

 

[isladogs]

Perhaps the new form is unbound or uses a local table as its record source

To relink the tables on the 'problem' workstation:
Click External Data ...Linked Table Manager

Tick the checkbox in the bottom left corner then Select All.
The OK button will be enabled. Click it.
You will be prompted to select the new location.
Follow the prompts.
When done you should see a message saying all tables have been successfully relinked.
NOTE if you have more than one BE, you will need to deal with the linked tables for each in turn

 

[theDBguy]

Hi Tim,

Pardon me for jumping in. If the problem turns out to be the tables needed to be relinked, it would mean you and your co-worker have a different mapping to the server. To avoid issues like this, consider using the UNC path to the server rather than a mapped drive.

 

[June7]

OP says everything works on his computer, but not on coworker's so can't be issue of button/event naming.

Is the code all macros or all VBA or mixture?

If table links were not valid, opening objects should error, not just do nothing.

Your in-house users should never have to re-link tables. Options:

1. make sure users have same drive mapping used for table links

2. use UNC pathing for table links, I use VBA to set these links in FE before distribution (of course, then IT decides to get new servers and change naming convention, so I had to change links and manually install new FE for each user)

If you want to provide files for analysis, follow instructions at bottom of my post.

Users really should not interact with tables and queries, just forms and reports.

 

[Zydeceltico]

If this has never worked, the answer is one thing. If this stopped working, the answer is something else. The fact that a recently created form works says that the switchboard is capable of opening forms, so that capability is not broken. (So that means that we must look elsewhere.)

Two possibilities come to mind, both involving the button-click code behind the launcher buttons you created.

The buttons were created using the default "embedded macros" rather than VBA - FWIW.

Sub-case A: Have you recently renamed the button controls since they were first built? Because the event name and event entry point are intimately related, if you have renamed buttons, you must rename and re-establish the event entry points. There is a variant of this that if you did a global replace of something AND that something could have been part of the button name, it would inadvertanly be part of the event name, too. So if you changed the event name rather than the button name, your problem would still be that you have a mismatch between the button-click event name and its corresponding button name. Doesn't matter which side is broken.

I didn't change any names.

This might be so simple as to get the correct spelling of the command button name, find the correct event code routine under the old name, rename the entry point, and go back and re-establish that you want to use event code. It will start to create a new event but then will detect that code already exists for that event and will just establish the new link - silently. You could also get into the VBA editor and look for all "_Click" strings (with "match whole words" NOT checked) to verify the event names match the buttons.

See above. I didn't change any names.

Sub-case B: Something has gone wrong in the event code or the whole form. If you have error handling enabled in the event routine, make it do something very visible - like pop up a message box to tell you that somehow you have screwed the pooch by breaking something.

If you have error messages disabled, enable them now so you can find the error.

Is there a way to enable error messages for macros? BTW - I don't have a problem changing all the "on-click open form" macros to VBA if that is a better idea.

Thanks!

TIm

 

[Zydeceltico]

Perhaps the new form is unbound or uses a local table as its record source

To relink the tables on the 'problem' workstation:
Click External Data ...Linked Table Manager


Tick the checkbox in the bottom left corner then Select All.
The OK button will be enabled. Click it.
You will be prompted to select the new location.
Follow the prompts.
When done you should see a message saying all tables have been successfully relinked.
NOTE if you have more than one BE, you will need to deal with the linked tables for each in turn

I only have one backend. I did all of this and there was no change in functionality.

 

[Zydeceltico]

Hi Tim,

Pardon me for jumping in. If the problem turns out to be the tables needed to be relinked, it would mean you and your co-worker have a different mapping to the server. To avoid issues like this, consider using the UNC path to the server rather than a mapped drive.

If my co-worker and I have different mappings to the server wouldn't it be the case that nothing at all would work? As I mentioned, all queries function properly from his front end and one recently created data entry form. I should note that I created the new form on MY desktop before splitting the database. It is not the case that I split the db, placed the BE on the network and then distributed the FE. The new form was created on my desktop prior to splitting and in exactly the same manner that all other forms were created.

What do I need to know about UNC paths? I am unfamiliar with this term.

Thanks,

Tim

 

[The_Doc_Man]

@June7, I was covering all the bases I could think of, but your point is correct. If it works one place and not in another, this SHOULD be something other than naming. But I have to ask to be sure that the "broken" thing wasn't event linkages.

@Zydeceltico - UNC pathing is the OTHER type of file specification.

Traditional: Device:\path.path.path\file.typ

UNC: \\Computername\drivename\path.path.path\file.typ

UNC looks more like a web reference, but technically it is a NETWORK reference. If you were open up a drive letter's properties, perhaps using Device Manager or Windows Explorer (and MyComputer icon), you would see that each drive letter LOOKS like the first part of that UNC path.

I ran into drive letter mappings as an issue once. UNC pathing makes that situation impossible to encounter because you bypass everything related to drive letters.

As to whether different mappings would cause everything to stop working? That's actually a good question, but it depends on what you do behind the scenes. I can only suggest that it is possible the answer is "not until you do something that actually touches a linked table." Since Access allows dynamic relinking, it doesn't automatically kick you out for broken links. But if you try to use a broken link, that's when bad things happen.

Is there a way to enable error messages for macros?

I always thought they WERE enabled by default. But I suppose it is possible to have disabled them somewhere. For macros, I believe the action name is "SetWarnings" and you set it "True" or "False." You want warnings enabled, so set the warnings flag to true.

I don't have a problem changing all the "on-click open form" macros to VBA if that is a better idea.

Long-term, probably a better strategy. Short-term? Change ONE of the ones that doesn't work from macro to VBA. Then, on the machine having the problem, set a breakpoint on the VBA "OnClick" code under the button and single-step through the code to see what happens.

Have you ever played with the debugger before? If not, ask in a followup question. One or more of us would happily explain the steps.

 

[Zydeceltico]

OP says everything works on his computer, but not on coworker's so can't be issue of button/event naming.

Is the code all macros or all VBA or mixture?

If table links were not valid, opening objects should error, not just do nothing.

Your in-house users should never have to re-link tables. Options:

1. make sure users have same drive mapping used for table links

2. use UNC pathing for table links, I use VBA to set these links in FE before distribution (of course, then IT decides to get new servers and change naming convention, so I had to change links and manually install new FE for each user)

If you want to provide files for analysis, follow instructions at bottom of my post.

Users really should not interact with tables and queries, just forms and reports.

1. How do I accomplish checking his and my drive mapping?

2. I don't know anything about UNC paths. How do I learn about this?

And yes - all of the "on-clicks" are embedded macros.

Thanks!

Tim

 

[Zydeceltico]

I figured out how to get the UNC path. More later. THX everybody.

 

[Zydeceltico]

I tried using the UNC path in the Linked Table Manager. It is still the same scenario.

And the single form that was recently created still works. In fact, I deleted the FE from both my and my coworkers computers and the BE from the network. I made another copy from my working backup and created yet another new form. This work was done entirely on my desktop - NOT on the network.

I created yet another new data entry form.

Then - on my desktop I:
1) split the DB
2) moved the BE to the network drive
3) renamed the FE on my desktop to QC DB FE
4) attached the FE on my desktop to an email and sent that email to my coworker who downloaded it to his documents folder.
I had him open the FE on his desktop and I relinked using the UNC path.
5) Then I had him restart the FE
6) successfully opened the brand new form I just created and it works as it should. This was opened from the form list - NOT from a button on my main form
7) I then had him open the other recently opened form which also worked as it should
8) I then had him try the other forms that have not worked (they don't even open). I had him try opening them with the button on the main menu form and also by double-clicking the form itself in the Navigation pane. Neither approach opens 5 of seven forms.

NOTE: I just noticed something ALL of the forms that won't open for my coworker I designed as pop-ups. The two new ones I did not designate as pop-ups. I am certain that this is the likely culprit. I would prefer that they remain pop-ups but it isn't entirely necessary. Is there an easy way to make this happen?

Thank you all for your assistance.

Tim

 

[Zydeceltico]

Actually - I just discovered that I very much need to know how to reference popups.

Popups still work fine on my FE on my desktop where I originally split the db and after placing the BE on the network but they do not work on my coworkers FE and there are a couple of conditions where the popup must work (e.g., a popup form that allows the user to enter dimensions in feet, inches, and decimal fractions).

FYI - I changed all of the main forms to not be popup and now they all work as expected.

However, there are at least two instances where it is critical to use popup forms which I detail below.

I've attached the unsplit db as a zipped file. There are two buttons on frmMillInspection that open a popup form. The button labels are Length Required and Length Actual. They work fine on my desktop - and not on my coworkers. On my coworkers they do not open which results in his front end being frozen as since they do not visibly open he cannot close them or cancel them.

Thank you for your insight in advance.

Tim

 

[theDBguy]

Hi,

To help us help you troubleshoot this problem, would you mind posting a copy of your FE and a copy of the FE from your co-worker’s machine for a comparison? Thank you.

 

[Frothingslosh]

Here is a silly question.

Do both you and your co-worker use the same number of monitors, and in the same basic placement?

 

[theDBguy]

Ooh, that’s a good thought.

 

[Frothingslosh]

Easy fix if I'm right. Pop-ups suck that way sometimes.

 

[Zydeceltico]

Here is a silly question.

Do both you and your co-worker use the same number of monitors, and in the same basic placement?

HA! You know - - - that's not a silly question.

NO - I have two and run it on my second monitor as the monitor is bigger.

He does not have a second monitor.

I see where you are going with this.

Leaving work now - will rearrange tomorrow.

I believe you might have just won the prize if my assumption is correct that you are proposing that popups are relative to screen location.



Thanks - I'll let you know tomorrow.