SOLVED

Managed Metadata Field

Iron Contributor
Hello.
I've linked a SharePoint field to my db. The list has one of those mis-supported managed metadata fields which links to Access as a simple text field. ??
Anyway around this?
Thanks
6 Replies
best response confirmed by Carl_Williams (Iron Contributor)
Solution

@Carl_Williams 

 

Given that this type of field isn't supported in Access, and can't be reliably used, my suggestion would be to avoid it entirely for the purposes of your Access relational database application. 

This is part of a larger pattern, IMO, in which SharePoint lists are a world unto themselves. We can't reasonably count on them outside of that environment. If you stick to SharePoint, of course, they're fair game.

 

I actually like the idea of SharePoint lists as a backend for some specialized Access solutions because of the fact that you can use them off-line as well as while connected, and because they are reachable via an internet connection from multiple locations.


That said, and repeating myself, because of their unique internal construction, I would avoid any but the basic datatypes like numbers, text and dates.

 

Your experience may vary, but that's how I see it.

Thanks George. Yes, this is the only way to create nice reports but a heck of a lot of tabular messaging is required, far too much IMMHO since MSFT products are purportedly so integrated.
Seems these managed metadata fields are an issue in and out of SharePoint and certain, necessary, expected functionality has been .......................................overlooked. Overlooked for several years.
Thanks again, you basically told me what I was expecting and have even started throwing away my managed metadata fields and lookups since simple things like filtering and "proper" parent/child or cascading functionality has been overlooked, some for a decade some for 2 decades, but who's counting.

Message received, steer clear of MMD fields. Might as well just make everything into a text field nowadays.
Happy holidays,

@Carl_Williams 

Within OFFICE itself (Word, Excel, Outlook, Powerpoint and Access) integration is pretty good. They're all dependent on VBA, for example. Otherwise, it's not so much. Another aspect is, no doubt, the fact that SharePoint Lists may be built on SQL Server, but they're heavily customized for the SP environment. I know Access/SQL Server devs who go so far as to reject SP lists as anything to do with relational design.

You mention Lookups. Another Soap Box™ of mine. For reason outside the scope of this forum, I have been trying to learn enough about PowerApps to work with them to create mobile hybrid apps (run in Access, with extended functionality on a smart device). Long story short, I used SP instead of SQL Server or SQL Azure for the back end. I chronicle one of my adventures in a YouTube video series about figuring out how Lookup fields really work in PowerApps. I'd love to be proven wrong, but my current opinion is that I'm going to bite the bullet and pay extra for SQL Azure in future PowerApps applications.


Interesting story!! Yes, I have many many soapboxes on my belt. It just seems some stech is great but EVERYTHING seems built on the premise; you have a 4" tube and need 1" string protruding from each end but Microsoft only provides a 5" string. One must now need to spend exorbitant and unjustified time to create workarounds and hack since most projects are never completed and much is overlooked. Much more time needs to be spent on creating connections to inane social media an d other services rather than COMPLTING a tech project.
Reza Domani has some excellent videos on PowerApps.
I have a lot of those but no longer use them because the flows that run them constantly get turned off. Again....???????????????????????
I'll check out your video.
Tx Geroge. Cheers
I rely heavily on Reza and on Shane Young.
Yes, they have some great content!! THEY should work with Microsoft to get info and PnP out in a more user friendly manner. Everything needs to be a week of research just to pul off one workaround or hack since the tech has overlookedonpourpose functionality. Do I sound like a broken record? Just figured, the squeaky wheel gets the grease.
1 best response

Accepted Solutions
best response confirmed by Carl_Williams (Iron Contributor)
Solution

@Carl_Williams 

 

Given that this type of field isn't supported in Access, and can't be reliably used, my suggestion would be to avoid it entirely for the purposes of your Access relational database application. 

This is part of a larger pattern, IMO, in which SharePoint lists are a world unto themselves. We can't reasonably count on them outside of that environment. If you stick to SharePoint, of course, they're fair game.

 

I actually like the idea of SharePoint lists as a backend for some specialized Access solutions because of the fact that you can use them off-line as well as while connected, and because they are reachable via an internet connection from multiple locations.


That said, and repeating myself, because of their unique internal construction, I would avoid any but the basic datatypes like numbers, text and dates.

 

Your experience may vary, but that's how I see it.

View solution in original post