In part three I said there was bit of functionality left to clear up.
We have to run the process manually.
We actually did a little bit of the ground work in part two.
One of the pieces of code was the main function that brings all the bits and pieces together – it was called “Fetch_Tweets”
Public Function Fetch_Tweets() As String
Dim strID As String
Dim strXML As StringIf Get_Settings = False Then
Debug.Print "Couldn’t get settings"
End
End IfstrID = Get_Last_Tweet_ID
strXML = Get_Latest_Tweets(strScreenName, strUserName, strPassword, strID)SaveTmpXML strXML
Application.ImportXML strTempFile, acAppendData
Tidy_User_table
End Function
Take a look at the first word of this code block.
PUBLIC
By adding this we can reference the function outside of Access so I put together a vbscript to run the function. (essentially…programmer types will argue this isn’t what Public means but for the layman it’ll do here!)
Dim TweetDB
TweetDB = "C:\TweetPoint\Twitter.ACCDB"
Dim myAccess
Set myAccess = CreateObject("Access.Application")myAccess.OpenCurrentDatabase TweetDB, False
myAccess.AutomationSecurity = msoAutomationSecurityForceDisablemyAccess.Run("Fetch_Tweets")
myAccess.CloseCurrentDatabase
myAccess.Quit acQuitSaveNone
Set myAccess = Nothing
So just breaking this down.
The vbscript is essentially doing exactly the same as if you were running this manually.
First we create an instance of Access. (The same as opening the application)
Then we open the database we need.
Then we tell Access to run our “Fetch_Tweets” function.
The we close the database and close the application.
Simple!
The only caveat here is macro security. If you have your security in Access set to high or prompt then the vbscript won’t work.
Since I’m just doing this a proof of concept I turned the macro security off.
You’ll need to make your own decision about how to deal with this.
One suggestion though is to look at something called “Trusted Locations”
This article explains how to set that up.
We can then take this vbscript and run it as a scheduled task to run as often as you need.
The major downside to this is that the system that will run the vbscript will need to have Access installed.
I don’t think the Access runtime would be enough (I only tried it very briefly)
So that’s all of our basic functionality problems sorted
We can ask Twitter to return the tweets for a given person, have them displayed in a SharePoint list automatically and it will be intelligent enough to not give us duplicates.
I’ll follow this up with a couple of posts that shows how to add a little more polish and cover a problem that I’ll need to look at going forward. I haven’t figured out what to do about it yet though!
Latest posts by Andy Parkes (see all)
- Dishley parkrun, Loughborough - August 1, 2023
- Woodgate Valley Country Park parkrun - July 22, 2023
- Abbey Park parkrun - June 8, 2023
2 thoughts on “SharePoint as a Twitter Client. Sort of – Part Four”