I’ve found the first bug/error in SharePoint that wasn’t my fault.

No really. Cereal.

It would’ve been nice to know about it beforehand, as I could’ve designed around it and created the same functionality with different controls and macro actions. (“BrowseTo”)

Now, this forces me to re-create a lot of the work I’ve done because I’ve already painted myself in with this broken method.

The issue exists in Microsoft Access 2010 web databases, and only appears when they’re uploaded to a SharePoint 2010 Server (which hosts them using Access Services).

If you’ve every used a TabControl in Access before and develop Web Databases, this is for you.

I’ve been developing the Inventory system we use for our company the past 3 years now, and this is the first time I’ve run into something like this. Normally Access is RELIGIOUS about not letting you upload code to the server that’s not compatible. This one must’ve slipped their minds. They had enough sense to write a custom error for it tho?

Here is the error:

When will you run into this? If you have any TabControls and you try to add any sort of automation for your users, you will eventually. You know, the kind the makes life more convenient?

Here is a dialog form I have named “PartDetails”. It’s used when you’re browsing through the list of parts in inventory and click on a part number.

You will notice it has tabs, yes? A convenient and stylish way to separate the details of a individual part.

I set the form up to be multipurpose. There are several different types of lists and views in my application, each showing different info based on the objective. If a tech wants to pull a part he searches/scrolls thru the Inventory “Stock” list. If he is interested in seeing the quantity, location, description, maybe even a picture of the part, he clicks on the part number and it opens the PartDetails in a dialog straight to the “Stock” tab (which is the default tab, so it always opens to that tab).

Now what if another employee who is responsible for maintaining Inventory and ordering new stock wants to look up a part? Mind you, same part # but different data about it. They would go to the ‘Value’ or ‘Ordering’ list where they would also see a searchable list of all part numbers, but instead of locations & quantities they would see aggregated cost history showing Min Price, Max Price, Avg Price we paid for it in the past. Now, if a user wants to *click* on that part # to look into the Cost details…

Yep, that’s where the same PartDetails form would come in. Wouldn’t it be nice if it opened directly to the Cost tab to show users exactly what they’re looking for?

As far as I can tell thru my repeated testing, that’s impossible. You will hit that GoToControl error every time no matter where you place the code. Worst part is, there’s an easy workaround, if only you knew that sooner…

TabControlTest.accdb (1.12 MB)

This is a test database I built demonstrating the error. Note that everything will work successfully in your Access 2010 CLIENT, it’s only when you upload to a SharePoint 2010 Server that you run into the GoToControl error. There is a workaround using “BrowseTo” included in the sample db that will work both in the client and on the web.

Reproducing the error yourself is simple enough: Create a new blank web database in Access 2010. Discard the table it gives you, we won’t need any data for this. Create a new blank web form, and place a TabControl on it. It should have two tabs at least, named something like Page0 and Page1. Now above the TabControl (or where-ever) create a button, and for the macro action do GoToControl=Page1. You will notice it autofills page names, a good indicator you’re on the right track.

Now close and save the form and open it again. With it open on Page0, click the button you just made. It should take you directly to Page1, no? Good!

Now, let’s upload our database to a SharePoint 2010 server. To do that you will have to set the db’s “Web Display Form” which is under Options. Once uploaded successfully, open it in a web browser. Now click your button. You should get the error now. This proves the bug exists in Access Services alone.

Even with “Page1” selected and loaded, GoToControl fails with the same error, proving it doesn’t matter if the tab Page is ‘loaded’ or not.

In my web application PartDetails is a windowed popup dialog, whereas in this sample db there is no popup and the TabControl exists in a single form with the GoToControl so all the action is contained in the same place.

I’ve tried “selecting” the TabControl first with GoToControl=TabCtrl1 and then navigating to Page1, no dice. I’ve tried moving the button inside a Page on the TabControl, it doesn’t matter.

To be fair, the error describes in detail exactly what is happening: “GoToControl cannot be used to go to a subform control or tab page in Web forms.” When it says it can’t, it means it can’t.

…aaaand here’s the workaround method. You can see “Tab1” and “Tab2” really are just buttons formatted to have no background color. They use BrowseTo to switch out which subform appears in the single Subform Control, just like an iframe.

This method is clean, works well, and I believe may actually be more efficient performance-wise from what I’ve observed so far.

Lesson learned: Never use TabControls on the web.

Now comes the ominous task of nearly completely re-doing my PartDetails form. It’ll be worth it once it’s done, that’s what I keep telling myself…

Access 2010 SP2 version: 14.0.7104.5000
SharePoint 2010 Server (Access Services) SP2: 14.0.7015.1000
SharePoint 2010 Build Numbers